"Down" Is a Decision, Not a Threshold
Microsoft recently talked publicly about Brain, the internal AI system that watches Azure's health and also decides when Azure is officially down. Declaring that a platform is having an outage sounds like it should be a simple threshold. Some metric crosses a line, you open an incident. In practice the "officially" part is a judgment call, and getting it wrong in either direction can be expensive.
Call out an outage that isn't real and you've burned trust, sent people digging into a problem that isn't there, and wasted their time. Miss a real one and your customers find out before you do. Brain's job is to pull together a lot of different data points (platform telemetry from across its services, regions, and workloads) and make that call in real time. That way the status Azure communicates matches what's actually happening. To be clear, Brain does a lot more than declare outages. Microsoft says it also powers Azure's customer resource-health notifications and its deployment safeguards.
But the "is it actually down" call is the piece I want to focus on here. It's the decision a lot of teams tend to get wrong, and it maps directly to how you set up alerting. We end up talking a lot about this exact problem with customers, just at a smaller scale than Azure. Most of them don't need an internal AI to run a status page. What they do need is to stop treating a single metric crossing a static threshold as the definition of "down." That's usually where alerting credibility falls apart.
Why static thresholds create noisy alerts
Here's the pattern we tend to see. A team wires up one monitor per metric, each with a static threshold, and every one of them is an independent trigger. CPU over 80%, error rate over 2%, p95 latency over 500ms, and so on. Each fires on its own. So a deploy blips the error rate for thirty seconds and everyone gets paged, or CPU spikes during a nightly batch job and it looks like an incident.
The team quietly learns to ignore the alerts. Then the one time several of those signals move together (which is what a real outage actually looks like) it gets lost in the noise. The data is all there. What no single signal gives you is a reliable stand-in for "the service is down," and static thresholds treat every one of them as if it were one.
What 'down' actually means
So it's worth writing the definition down before any tooling gets involved. A service is down when your users can't do the thing they came to do. Not when CPU is high, and not when one error rate monitor crossed a line for thirty seconds. Those are symptoms. Symptoms are useful, but they need something to confirm them before anyone declares an outage or gets woken up. That definition gives you two jobs: measure the user experience directly, and check the surrounding evidence when that measurement fails.
Measuring the user experience directly with synthetic tests
The most direct way to measure the user experience is to test it on purpose, and that's what Datadog's Synthetic tests are for. An API test can run your health check or your login flow from managed locations around the world, every few minutes, all day. A browser test can click through checkout the same way a customer would. Tag the tests with `service` and `env` so a failure shows up carrying its context, not as one more anonymous alert. When a synthetic test fails, that is a user-shaped request failing, and it's as close to "down" as anything you can measure gets.
Letting Bits AI confirm what a failed test means
A failed test still needs validation, because "is it down or is it just me" applies to your test runner too. Datadog Bits AI can turn that failed test into an answer. You can configure the test's monitor to automatically launch a Bits investigation whenever it enters an alert state (Synthetics support is in Preview). From there, Bits works the problem the same way an on-call engineer would: it forms a hypothesis about the root cause, queries the telemetry to check it, and repeats. Along the way it reads traces and logs, checks recent deploys through Change Tracking, and pulls in what Datadog Watchdog's machine learning flagged. When it's done, you get either a conclusion backed by the evidence it gathered or an investigation it marks inconclusive.
That combination answers the question we started with. The synthetic test says something user-facing failed from outside your infrastructure, and Bits reports whether the rest of the telemetry agrees and what changed. So when the page goes out at 3am, the on-call opens to more than a blank dashboard. They start from "the login flow is failing from three regions, it started right after this deploy, and here's the evidence." That's essentially what Azure Brain does, scaled down to a team: multiple data points pulled together into one call made in real time.
Scaling this approach for larger environments
If you're running a larger environment, there's a bigger version of the same idea. Keep the per-metric monitors, but stop treating each one as its own verdict. Datadog Event Correlation can group related alerts based on their relationships or on rules you define, so a real problem shows up as one correlated issue instead of twelve separate pages. Route that correlation into an incident and point Bits at the incident instead of any single alert. Now the 3am question is whether several independent signals firing together are actionable, and you already have Bits looking into it. That beats staring at twelve separate alerts trying to guess which to open first.
These per-metric building blocks still have a place inside this design, as long as none of them declares an outage on its own. Composite monitors let the paging condition itself demand agreement: error rate high `&&` latency degraded `&&` health check failing, before anyone gets paged. Anomaly detection monitors keep a service's normal rhythm from reading as an incident, so a checkout flow doing 10x volume at noon doesn't page just for being busy. And SLO burn rate alerts stay the "officially" layer, because error budget burn measures the user-facing promise directly instead of standing in for it. Now each one is an input to the outage decision, not a competing definition of it.
Designing alerts around one definition of down
None of this needs Microsoft's scale or a custom AI system. It takes a written definition of "down" for the two or three services that actually matter: a user-shaped request fails, and the surrounding evidence agrees. Wire synthetic tests to the critical flows, let a failed test launch the investigation, and put correlation in front of the monitor pile so an incident arrives as one issue. Brain is a useful reminder that even at Azure's scale, the data was always there. The hard part is deciding what it means, and that decision should be made when you design the alerts, not after.
Alerting still noisy?
If your team is stuck reacting to false alarms instead of real outages, NoBS can help you design monitors, synthetic tests, and correlation rules that actually reflect when something's down.
FAQ: Deciding When a Service Is Actually Down
Last updated: August 12, 2026
What is Azure Brain?
Brain is Microsoft's internal AI system that watches Azure's health and decides when the platform is officially experiencing an outage. It pulls together platform telemetry across Azure's services, regions, and workloads to make that call in real time.
Beyond declaring outages, Microsoft says Brain also powers Azure's customer resource-health notifications and its deployment safeguards.
Why isn't a single metric crossing a threshold enough to call an outage?
A team wiring up one monitor per metric, each with its own static threshold, ends up with every monitor acting as an independent trigger. A deploy that blips the error rate for thirty seconds, or a CPU spike from a nightly batch job, pages the team even though nothing is actually down.
Teams learn to ignore these alerts. Then when several signals genuinely move together, which is what a real outage looks like, it gets lost in the noise.
What's the actual definition of "down"?
A service is down when your users can't do the thing they came to do, not when CPU is high or one error rate monitor crossed a line for thirty seconds. Those are symptoms, and symptoms need something to confirm them before anyone declares an outage.
That definition gives you two jobs: measure the user experience directly, and check the surrounding evidence when that measurement fails.
How do synthetic tests measure the user experience directly?
Datadog's Synthetic tests run a scripted check, like a health check, login flow, or checkout, from managed locations around the world, every few minutes, all day. Tagging tests with `service` and `env` means a failure carries its context instead of showing up as one more anonymous alert.
When a synthetic test fails, that's a user-shaped request failing, which is about as close to "down" as anything you can measure.
How does Bits AI confirm a failed synthetic test is real?
A test's monitor can be configured to automatically launch a Bits investigation whenever it enters an alert state (Synthetics support is in Preview). Bits works the problem the way an on-call engineer would: forming a hypothesis, querying telemetry to check it, and repeating.
Along the way it reads traces and logs, checks recent deploys through Change Tracking, and pulls in what Watchdog's machine learning flagged. It returns either a conclusion backed by evidence or marks the investigation inconclusive.
What about larger environments with lots of monitors already in place?
Keep the per-metric monitors, but stop treating each one as its own verdict. Datadog's Event Correlation groups related alerts based on their relationships or defined rules, so a real problem shows up as one correlated issue instead of a dozen separate pages. Route that correlation into an incident and point Bits at the incident.
Composite monitors, anomaly detection monitors, and SLO burn rate alerts all still have a place, as inputs into that decision rather than competing definitions of it.
What's the practical first step for a smaller team?
Write down a definition of "down" for the two or three services that actually matter, then wire synthetic tests to those critical flows. Let a failed test launch the investigation automatically, and put correlation in front of the monitor pile so an incident arrives as one issue rather than twelve alerts.
None of this requires Microsoft's scale or a custom AI system. The data is already there; the decision just needs to be designed into the alerting up front.
