What is uptime monitoring?

Uptime monitoring is the practice of having a machine outside your infrastructure request your service on a fixed schedule, check that the response is genuinely correct, and alert a human when it is not.

That is the whole idea. Everything below is detail about the three parts people get wrong: what you check, what counts as correct, and who you wake up.

A check is a request plus an assertion

Most people picture uptime monitoring as a ping. A machine somewhere asks whether you are there, your server says yes, a dashboard stays green.

That is half of it, and it is the easy half. The part that decides whether the tool is worth anything is the assertion: the rule that turns a response into a verdict. Consider what a status-code check sails straight past:

• Your app returns 200 and renders a stack trace.
• Your homepage loads perfectly and your checkout is broken.
• Your API answers in 40ms with a body that says the database is unavailable.
• Your certificate expires in three days and every response is a healthy 200 until the morning it is not.

In all four the server is up and the service is down. The useful question was never whether it responded. It is whether it responded correctly, and that is what the different check types exist to express.

The nine kinds of check, and what each one proves

Each of these asserts something different, so the interesting column is the second one.

One of those works backwards from the rest. Every other check reaches out to something and waits for a reply, but a nightly batch job has no address to reach. There is nothing to poll, so nothing turns red when the work simply never runs. A heartbeat check inverts the arrangement: the job reports in when it finishes, and the monitor alerts on the silence. Scheduled work failing quietly is one of the most commonly missed classes of outage, precisely because the usual approach has nothing to grab hold of.

How quickly will you actually find out?

An outage does not wait for your schedule. It starts whenever it starts, which means the gap until your next check is anywhere between nothing and one full interval, with every value equally likely. So a check running every 60 seconds finds a failure after 30 seconds on average and 60 at worst.

That distinction matters because interval and detection time get quoted as if they were the same number. They are not. The interval is the ceiling.

Add the confirmation step described next, which deliberately costs one more check, and then however long your alert takes to reach a person who is awake.

Shorter is also not automatically better. A ten-second check is 8,640 extra requests a day against an endpoint that probably talks to your database, and every additional sample is another chance for one unlucky blip to be read as an outage. The interval worth paying for is the one that matches how fast you could genuinely respond. Ten-second detection feeding an alert nobody reads until morning buys you nothing at all.

The first failure should not wake anyone

This is the design decision that separates a monitor people trust from one they mute.

A garbage-collection pause, a load balancer draining a node, brief packet loss, a DNS resolver hiccup: all transient, all self-resolving, and in a single sample all completely indistinguishable from a real outage. If one failed check pages someone, the tool becomes noise, and a muted monitor is worse than none at all because it still costs money while quietly supplying false reassurance.

So a failed check is better treated as a suspicion than a verdict. Concretely, here is what NoDisrupt does with one: the first failure opens the incident in a pre-alarm state and tells nobody. A different checker then re-runs the same check. If it fails too, the incident is confirmed and alerting begins. If it passes, the incident is deleted outright. It never lands in your history and it never counts against your uptime figures, because it was never an outage.

The cost of confirming is one extra interval before you hear about a genuine outage. For nearly every team that is a trade worth making, because the alternative is spending your alerting budget on noise.

What 99.9% actually buys you

Availability targets are easier to argue about in percentages and easier to understand in minutes.

Two things fall out of that table. The step from 99.9% to 99.99% is not a rounding difference, it is 43 minutes of monthly budget against four, and closing that gap is almost always an architecture problem (redundancy, failover, deploys that do not take a node with them) rather than a monitoring one. Monitoring measures the number. It does not move it.

The other is that a single 45-minute incident spends an entire 99.9% month. Which is why how fast you detect and repair matters far more than which interval you picked.

What to monitor, in order

Most teams do the first of these and stop. The rest is where the outages you did not see coming live.

What uptime monitoring will not tell you

An external check tells you that something is broken, and roughly where. It does not tell you why. Four questions it cannot answer, and the tool that can:

• Which of nine services in the request path was the slow one. That is distributed tracing.
• What the actual exception was. That is error tracking and log search.
• What one specific user experienced at 14:02. That is real-user monitoring and session replay.
• Whether a page renders correctly, or a JavaScript bundle broke in one browser. That is browser-level synthetic testing.

These are separate categories with very different price models, and conflating them is how teams end up metering pulse checks at observability rates. If that is the position you are in, the cost breakdown and the Datadog comparison both work through where the line sensibly falls.

To be plain about our own side of that line: NoDisrupt does not do APM, distributed tracing, log analytics, real-user monitoring or browser-rendered journey checks. If you need those, you need a tool that does them.

Detection is only the first half

An outage nobody was told about costs exactly as much as one you never detected. Whatever notices the failure has to reach a person who can act, which is the job of escalation policies: route the alert, and if nobody acknowledges it, route it somewhere else rather than letting it sit.

Then there is everyone outside the team. During an incident your customers are going to ask what is happening, one at a time, through whatever channel is most expensive for you to answer. A status page answers them all at once, and the wider job of running the incident itself, from raising it to writing up what happened, is incident management.

Common questions

Working out which tool fits? The cost comparison takes your real monitor counts, and every check type has its own page.