Why "It's Down" Should Never Come From a Customer First

There's a specific kind of dread in getting a support email that starts with "hey, is your site down?"

It means the outage has already been happening long enough for a stranger to notice, decide it's worth writing in about, and wait for a reply, before anyone on your team knew there was a problem at all. It also means every silent minute before that email arrived was a minute where more people than just the one who emailed were affected, and most of them never bothered to say anything.

That gap, between something breaking and someone internally finding out, is where the real damage happens, not in the technical failure itself but in everything that happens, or doesn't happen, while it goes unnoticed. Here's what the numbers actually say about how often that gap opens up, and why.

The Numbers Behind the Problem

53% of outages are first reported by customers, not caught by internal monitoring. That's not a rare edge case, it's roughly half. For every outage a team catches on their own, there's nearly one more where the first signal comes from someone outside the company, which means the team is already behind before they've even started fixing anything.

62% of scheduled jobs run with no failure alerting at all. Backups, billing runs, report generation, queue workers, the unglamorous background processes that don't have a user staring at them in real time are also the ones most likely to fail with nobody watching. A website going down gets noticed eventually because someone tries to load it. A cron job that silently stops running might not get noticed until someone goes looking for output that was supposed to exist and finds nothing.

34% of incidents involve an expired certificate. Certificate expiry is about as predictable a failure as exists in this list, it's not a surprise, it's a date you already knew, and it still accounts for roughly a third of incidents. That's a scheduling problem more than a technical one, and it's exactly the kind of failure that automated monitoring should make close to impossible.

41% of downtime goes unnoticed for 30 minutes or more. Half an hour doesn't sound catastrophic in isolation, until it's half an hour of a checkout flow returning errors, or an API silently failing for every integration partner relying on it. The cost of downtime isn't just its length, it's the length multiplied by however much was happening during it.

88% of users leave after a single bad experience. This is the number that makes the other four expensive. Downtime isn't just an inconvenience that resolves itself once the incident's over, for a meaningful share of the people who hit it, that one experience is enough to make them stop coming back at all.

Why This Keeps Happening

None of this is happening because teams don't care about uptime. It's happening because the failures that matter most are the ones that don't announce themselves.

A few examples of what that looks like in practice:

• A single-region check misses a real outage because it only looked from one place
• A cron job exits successfully 29 nights in a row, then silently stops running on the 30th, and nothing was watching for its absence, only for an error that never came
• A certificate with an expiry date sits quietly on a calendar nobody checks, and isn't a technical failure until the day it becomes one, all at once, in front of every visitor
• A third-party API a product depends on has its own outage, and from the inside, everything looks fine right up until customers start reporting that a specific feature has stopped working

The common thread is that dashboards can look green while something real is already broken. Uptime monitoring that only checks from one location can miss outages a customer in a different region is actively experiencing. Monitoring that only covers HTTP endpoints has nothing to say about a cron job or a certificate. And monitoring that alerts too aggressively on every regional blip trains teams to distrust their own alerts, which is its own way of ending up back at square one.

The Internal Cost of Hearing It From a Customer

There's a cost to this pattern that rarely gets discussed alongside the statistics above: what it does to a team's posture during the incident itself.

A team that catches its own outage starts from a position of control. They know what broke, they're already investigating, and any customer communication can lead with "we're aware and working on it." A team that finds out from a customer starts from behind on every front at once. They're simultaneously trying to diagnose the problem, verify the report is accurate and not a one-off issue on the customer's end, and figure out how widespread it actually is, all while that customer, and possibly others experiencing the same issue, are left without any acknowledgment at all.

The response ends up reactive and improvised precisely when a calm, prepared response would matter most. This also shapes how the incident gets remembered afterward, internally and by customers. "We caught it in 90 seconds and had a fix out in 20 minutes" is a fundamentally different story than "a customer had to tell us," even when the underlying technical fix takes the same amount of time either way.

The Cost of Finding Out Last

The 88% churn figure is worth sitting with, because it reframes what the other numbers actually cost.

A 53% first-reported-by-customer rate isn't just an internal embarrassment, it's a direct hit to however many of those customers don't come back. A silently failing cron job isn't just a missed backup, it's the version of your product that a customer experienced during however long it took someone to notice. Downtime that goes unnoticed for 30 minutes isn't a rounding error, it's 30 minutes of however many people were affected deciding, in real time, whether this is a product they trust.

These numbers also aren't independent of each other, they compound. A team with no cron alerting is more likely to be the same team without multi-region confirmation, without certificate monitoring, without a status page, because all of these tend to get built together, or not at all. A gap in one area is rarely isolated, it's usually a signal of the same underlying gap across several categories at once. That's actually good news in a way: closing the detection gap in one place tends to mean closing it everywhere, since the fix is rarely category-specific.

What Actually Closes the Gap

Closing this gap isn't really about monitoring harder, it's about monitoring the things that actually fail silently, not just the things that fail loudly. In practice, that means:

• Checking from multiple regions and confirming a failure from more than one location before treating it as real, so a genuine outage isn't missed and a network blip doesn't cause an unnecessary page
• Treating cron jobs and background tasks as first-class things to watch, not an afterthought bolted onto uptime monitoring, since a missed heartbeat is often the earliest and only signal that something's wrong
• Keeping certificate and DNS monitoring in the same place as everything else, so a predictable failure like an expiring cert stops being something that has to be remembered rather than something that's simply caught
• Giving customers a status page that updates itself from real monitoring data, so the first place they check during an incident tells them something true, instead of an inbox that takes hours to respond

Pricing

Downdar offers three plans, each with a 30-day trial (credit card required):

Starter at $9 per month includes 10 monitors with 5-minute checks across HTTP, Ping, TCP, SSL, and DNS, plus 10 cron & heartbeat monitors, email alerts, and 1 status page.

Growth at $29 per month includes 50 monitors and 50 cron & heartbeat monitors, 1-minute checks, multiple global checkpoints, custom alert channels (Slack, Discord, Telegram, Teams, webhook), and 5 embeddable status pages.

Scale at $99 per month includes 250 monitors, 250 cron & heartbeat monitors, 25 status pages, and priority support with an uptime SLA.

The Bottom Line

The goal isn't zero downtime, that's not realistic for anyone. The goal is being the first to know about it, every time, so the response starts the moment something breaks instead of the moment a customer gets frustrated enough to say something.

That's a solvable problem, and most of the numbers above trace back to the same fix: watching the things that fail quietly with the same seriousness as the things that fail loudly. The difference between a team that catches 90% of its incidents internally and one that catches half isn't usually effort or headcount, it's whether the monitoring in place actually covers the failure modes that don't announce themselves.