{"id":2749,"date":"2026-05-06T09:30:00","date_gmt":"2026-05-06T09:30:00","guid":{"rendered":"https:\/\/mugnos-it.com\/?p=2749"},"modified":"2026-03-24T12:45:20","modified_gmt":"2026-03-24T12:45:20","slug":"what-are-the-four-golden-signals-quality-monitoring","status":"publish","type":"post","link":"https:\/\/mugnos-it.com\/pt\/what-are-the-four-golden-signals-quality-monitoring\/","title":{"rendered":"What are the “Four Golden Signals”? Quality Monitoring"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

<\/p>\n\n\n\n

What are the “Four Golden Signals”? Quality Monitoring<\/p>\n\n\n\n

<\/p>\n\n\n\n

You’re drowning in metrics. Your monitoring dashboard has 47 panels. You’re getting paged for CPU spikes at 3 AM. And when something actually breaks, you still don’t know where to start looking.<\/p>\n\n\n\n

Sound familiar?<\/p>\n\n\n\n

This is exactly the problem the “Four Golden Signals” solve. These four metrics\u2014Latency<\/strong>, Traffic<\/strong>, Errors<\/strong>, and Saturation<\/strong>\u2014form the foundation of effective SRE monitoring. They’re not fancy. They’re not new. But they work because they answer the question every operator asks: “What’s actually broken?”<\/em><\/p>\n\n\n\n

The Four Golden Signals: Your Monitoring North Star<\/h2>\n\n\n\n

The Four Golden Signals come from Google’s Site Reliability Engineering book and represent the core metrics you must monitor<\/strong> in any system, regardless of complexity. They’re not about perfecting your observability stack\u2014they’re about starting with what matters.<\/p>\n\n\n\n

Think of them as the four vital signs of your infrastructure.<\/p>\n\n\n\n

Signal 1: Latency \u2014 How Long Are Things Taking?<\/h2>\n\n\n\n

Latency<\/strong> is the time your system takes to respond to a request. It’s the most visible metric from a user’s perspective: How long does it take to load a page? How long to execute a database query? How long for your API to respond?<\/p>\n\n\n\n

Latency is tricky because it’s not uniform. You have:<\/p>\n\n\n\n

    \n
  • Internal latency<\/strong>: Function calls, database queries, cache lookups<\/li>\n\n\n\n
  • External latency<\/strong>: Network calls to third-party services, downstream APIs<\/li>\n\n\n\n
  • Request path latency<\/strong>: The end-to-end time from request arrival to response delivery<\/li>\n<\/ul>\n\n\n\n

    From an SRE perspective, latency connects directly to SLOs<\/strong>. If your SLO says “p99 latency < 200ms,” you need to monitor that p99 continuously. If you’re consistently hitting 250ms, you’re burning through your error budget fast\u2014and users notice.<\/p>\n\n\n\n

    How to start<\/strong>: Pick your critical user journeys (login, search, checkout). Measure their latency at the p50, p95, and p99. Tools like AWS X-Ray, Datadog APM, or New Relic give you this granularity without guessing.<\/p>\n\n\n\n

    Signal 2: Traffic \u2014 How Much Load Are You Handling?<\/h2>\n\n\n\n

    Traffic<\/strong> measures the volume flowing through your system: How many requests per second? How many database inserts? How many messages in your queue?<\/p>\n\n\n\n

    Traffic is your early warning system. A sudden spike in traffic can explain a cascade of failures:<\/p>\n\n\n\n

      \n
    • High latency? Check traffic. Maybe you’re getting 10x normal load.<\/li>\n\n\n\n
    • Database struggling? Check traffic. Maybe an agent started generating garbage requests.<\/li>\n\n\n\n
    • Memory usage climbing? Check traffic. Maybe someone misconfigured a retry loop.<\/li>\n<\/ul>\n\n\n\n

      From an SRE perspective, traffic patterns tell you whether you’re within capacity<\/strong>. If your system can handle 1,000 req\/s but you’re now seeing 2,000 req\/s, saturation (your fourth signal) will follow. Understanding traffic lets you scale before you break<\/strong>.<\/p>\n\n\n\n

      How to start<\/strong>: Instrument key flows (API requests, database transactions, message publishing). Use rate-based metrics from Prometheus, CloudWatch, or Datadog. Alert on anomalies: “Request rate jumped 50% in 5 minutes.”<\/p>\n\n\n\n

      Signal 3: Errors \u2014 How Many Requests Are Failing?<\/h2>\n\n\n\n

      Errors<\/strong> are requests that didn’t succeed. They come in forms:<\/p>\n\n\n\n

        \n
      • HTTP 4xx (client error) and 5xx (server error) responses<\/li>\n\n\n\n
      • Failed database transactions<\/li>\n\n\n\n
      • Exceptions in logs<\/li>\n\n\n\n
      • Timeouts on downstream services<\/li>\n<\/ul>\n\n\n\n

        Errors are the most direct signal that something is broken. But here’s the catch: not all errors are visible in HTTP status codes. You need to monitor:<\/p>\n\n\n\n

          \n
        • API error rates (4xx and 5xx)<\/li>\n\n\n\n
        • Application exception rates (check your logs)<\/li>\n\n\n\n
        • Failed transactions in your database<\/li>\n\n\n\n
        • Timeout rates on external service calls<\/li>\n<\/ul>\n\n\n\n

          From an SRE perspective, error rates feed directly into your SLI<\/strong> (Service Level Indicator). If your SLO is 99.9% availability and you’re at 99.5%, you’re burning error budget. Catching this early means you can act before breaching the SLO.<\/p>\n\n\n\n

          How to start<\/strong>: Query your logs for error patterns. Set up alerts: “Error rate > 1% for 5 minutes” or “5 errors in 1 minute on the checkout endpoint.” Use structured logging to make errors searchable.<\/p>\n\n\n\n

          Signal 4: Saturation \u2014 How Full Is Your System?<\/h2>\n\n\n\n

          Saturation<\/strong> measures how much of your resources you’re using: CPU, memory, disk I\/O, database connections, queue depth.<\/p>\n\n\n\n

          Saturation is the sneakiest signal because it’s a leading indicator<\/em> of problems. High saturation doesn’t mean you’re broken yet\u2014it means you’re about to be. When CPU hits 90%, latency climbs. When memory swaps, everything slows. When your connection pool maxes out, requests queue.<\/p>\n\n\n\n

          From an SRE perspective, saturation is tied to resilience<\/strong>. A system at 100% saturation has zero headroom to handle traffic spikes, failovers, or unexpected load. This violates the SRE principle of static stability<\/strong>\u2014your system should degrade gracefully under load, not catastrophically.<\/p>\n\n\n\n

          How to start<\/strong>: Monitor the basics on every instance: CPU, memory, disk usage. Monitor application-level saturation: database connection pools, queue lengths, thread pools. Alert at 70-80% saturation, not 95%.<\/p>\n\n\n\n

          Putting It Together: Troubleshooting With the Four Signals<\/h2>\n\n\n\n

          Here’s how they work together. A user complains: “The site is slow!”<\/em><\/p>\n\n\n\n

            \n
          1. Check Latency<\/strong>: p99 latency is 800ms (normal is 200ms). \u2713 Confirmed slow.<\/li>\n\n\n\n
          2. Check Traffic<\/strong>: Requests per second are 2x normal. \u2713 We’re under load.<\/li>\n\n\n\n
          3. Check Errors<\/strong>: Error rate is 0.1% (normal). \u2713 No widespread failures.<\/li>\n\n\n\n
          4. Check Saturation<\/strong>: Database CPU is 85%, memory is 90%. \u2717 The database is saturated.<\/li>\n<\/ol>\n\n\n\n

            Root cause<\/strong>: Database can’t keep up with query volume. Action<\/strong>: Scale the database, optimize slow queries, or add caching.<\/p>\n\n\n\n

            Without these four signals, you’re guessing. With them, you have a repeatable troubleshooting process.<\/p>\n\n\n\n

            Why These Four? Why Not More?<\/h2>\n\n\n\n

            You might think: “But what about P50 latency? Memory leaks? Network drops?”<\/em><\/p>\n\n\n\n

            The Four Golden Signals work because they’re universal<\/strong>. Every system has latency, traffic, errors, and saturation. They’re simple enough that operators can remember them during incidents. And critically\u2014they’re correlated<\/strong>. Most problems show up in multiple signals at once.<\/p>\n\n\n\n

            This aligns with SRE’s principle of simplicity<\/strong>: you don’t need a perfect observability stack to be effective. You need the right metrics, measured well, with clear thresholds.<\/p>\n\n\n\n

            Getting Started: A Minimal Implementation<\/h2>\n\n\n\n

            You don’t need enterprise monitoring tools. Start here:<\/p>\n\n\n\n

              \n
            • Latency<\/strong>: Add timing logs (console.time()<\/code>, start = time.now()<\/code>) to critical paths<\/li>\n\n\n\n
            • Traffic<\/strong>: Count requests with a simple counter (requests_total<\/code> in Prometheus)<\/li>\n\n\n\n
            • Errors<\/strong>: Parse logs for errors and count them (errors_total<\/code>)<\/li>\n\n\n\n
            • Saturation<\/strong>: Collect host metrics (CPU, memory) from your OS<\/li>\n<\/ul>\n\n\n\n

              Set alerts on each signal at sensible thresholds for your system. When an alert fires, check all four before acting.<\/p>\n\n\n\n

              Conclusion<\/h2>\n\n\n\n

              The Four Golden Signals aren’t revolutionary. They’re not the latest monitoring trend. They’re durable because they answer the fundamental question of SRE: “Is my system healthy, and if not, where do I start looking?”<\/em><\/p>\n\n\n\n

              From an SRE perspective, these signals connect to everything:<\/p>\n\n\n\n

                \n
              • Latency<\/strong> feeds into SLOs and user satisfaction<\/li>\n\n\n\n
              • Traffic<\/strong> determines whether you’re within capacity<\/li>\n\n\n\n
              • Errors<\/strong> show direct impact on reliability<\/li>\n\n\n\n
              • Saturation<\/strong> reveals resilience and headroom for failure<\/li>\n<\/ul>\n\n\n\n

                Start measuring these four. Build alerts on them. Practice troubleshooting with them. You’ll find that 90% of your incidents become solvable with just these four metrics.<\/p>\n\n\n\n

                \n\n\n\n

                Stay tuned for deeper dives into building monitoring that actually helps you sleep at night.<\/strong><\/p>\n\n\n\n

                Cheers,<\/p>\n\n\n\n

                Douglas Mugnos<\/p>\n\n\n\n

                MUGNOS-IT \ud83d\ude80<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

                \n\t\t\t\t\t
                \n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

                What are the “Four Golden Signals”? Quality Monitoring You’re drowning in metrics. Your monitoring dashboard has 47 panels. You’re getting paged for CPU spikes at 3 AM. And when something actually breaks, you still don’t know where to start looking. Sound familiar? This is exactly the problem the “Four Golden Signals” solve. These four metrics\u2014Latency, […]<\/p>","protected":false},"author":3,"featured_media":2750,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2749","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/mugnos-it.com\/wp-content\/uploads\/2026\/03\/ChatGPT-Image-24-de-mar.-de-2026-09_44_06.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2749","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/comments?post=2749"}],"version-history":[{"count":4,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2749\/revisions"}],"predecessor-version":[{"id":2754,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2749\/revisions\/2754"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media\/2750"}],"wp:attachment":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media?parent=2749"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/categories?post=2749"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/tags?post=2749"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}