The demo had gone well. That's the part that makes this story worth telling.
Forty minutes in, everything had worked. The flows, the edge cases they asked about, the thing somebody tried that wasn't on the script. The room had that quality you can feel where people have stopped evaluating and started imagining using it. You know the feeling. It's the whole reason you do demos.
Then, in the last leg — the bit where you show the thing that ties it all together — a screen didn't load. Not an error page. Just a spinner, and then a blank panel where data should have been.
The cause turned out to be a background service nobody had thought about in four months. Not the API, not the database, not anything anybody would have described as important. A small thing that fetched and cached some data on a schedule, which had stopped running at some point, and nothing anywhere was watching it, so nothing anywhere knew.
Twelve seconds of a forty-minute demo.
That's the whole meeting now. Not in any formal sense — nobody wrote it down, nobody said anything unkind. But that's what they remember, and if you asked them a month later what they thought of the product, that's the shape of the answer.
What got damaged wasn't revenue
If you search for what downtime costs, you'll find numbers like $5,600 a minute and $300,000 an hour. Those are real figures from real reports, and they're about enterprises with revenue measured per second. For a startup they're not merely inaccurate, they're the wrong category — and I think quoting them is why most writing on this subject gets ignored by the people who need it most.
Nothing measurable was lost in that demo. No transactions failed. No customer churned that day. On a spreadsheet, the cost was zero.
What was lost was credibility, which is the actual currency a startup runs on. Credibility is what gets you the next customer, the next hire, the next cheque, the benefit of the doubt when something else goes wrong later. You can't invoice it and you can't measure it, and if you spend it you can't get it back on any timeline that helps you.
And it's asymmetric in the cruelest possible way. It accumulates slowly, through hundreds of invisible good decisions nobody will ever know you made. It collapses instantly, through one visible failure.
Nobody evaluates your architecture. They evaluate you.
Here's the thing that stings, and I want to be precise about why.
When that panel didn't load, nobody in the room thought: an unmonitored background job in a non-critical path stopped executing, which is a gap in their observability coverage rather than a flaw in their core engineering.
They thought: it broke.
Everything you built correctly is invisible. The schema you normalized properly, the race condition you caught in review, the migration you did carefully at 11pm so nobody would notice, the dependency you upgraded before it became a problem — none of that is perceptible to anyone. It generates no impression at all, because its entire output is the absence of trouble, and absence looks like nothing.
The one failure is the only visible artifact of your engineering that the room ever receives. So months of genuinely good work and one bad minute produce the same impression as months of bad work. That's not fair, but it isn't irrational either: people treat a failure in a demo as a sample of your reliability, not as an isolated incident. They're trying to estimate a quality they can't inspect directly, and you handed them the only data point they have.
If you're the technical person — the founder's technical cofounder, the lead, the one everyone tells people is the best developer they know — you feel this personally, because it is personal. That reputation took years. It's maintained entirely by things nobody sees. And it's exposed, in public, by the one thing that goes wrong.
It's always the little hidden service
That's not bad luck. It's structural, and once you see why, it changes what you monitor.
The important things get attention. The login flow, the payment path, the main API — those get tested, reviewed, watched, worried about. People ask about them in standups. If they break, they break early and loudly and someone notices.
The webhook handler that one integration uses. The thumbnail generator. The nightly job that refreshes a cache. The email queue worker. The certificate on the subdomain that nobody remembers provisioning. These get no attention at all, precisely because they're minor — and that's the problem, because minor describes how much you think about them, not how visible their failure is.
When one of them dies, it doesn't present as "a minor service is down." It presents as the product is broken, because users don't experience your architecture. They experience one screen that doesn't work. The size of a service has almost nothing to do with the size of its failure.
So the components most likely to fail silently are the ones nobody is watching, and the reason nobody is watching them is the same reason they fail silently. That loop closes on its own, and it closes on your worst day.
The only way out of that loop is to make watching something cheap enough that you'll do it for things you don't think matter. Which is mostly what I built CleverQA to be. Go back through that list of forgotten things and there's a check for each one:
- The nightly cache-refresh job — a heartbeat. It pings a URL when it finishes; if the ping doesn't arrive, you hear about it. One line appended to the crontab, no agent, no SDK.
- The certificate on the subdomain nobody remembers provisioning — a TLS check, with warnings at 30, 14, 7, 3 and 1 days. Expiry is the most predictable outage there is and it still takes people down constantly.
- The webhook handler one integration uses — an HTTP check with an assertion on the response body, which catches the version that matters: a 200 containing an error.
- The email queue worker — a heartbeat, or a TCP check on the queue itself.
- The specific database query that got slow — a database-query check that runs it and asserts it returns rows.
- The flow that ties it all together, the one that broke in that demo — a scripted browser journey. Up to thirty steps, in a real headless Chromium, asserting the text and URLs a human would see. When it fails, the error names the step that failed.
That last one is the one I'd set up first after a demo like that, because it tests the thing the room actually experienced rather than the components underneath it. Everything can be individually green and the journey still broken.
None of these take more than a few minutes to set up, and five of them fit on the free plan, which is the point. You will not do a careful observability review of your minor services. You might spend twenty minutes on a Tuesday adding six checks.
The real choice isn't whether it breaks
I want to be honest about what's actually on offer here, because there's a version of this argument that overpromises and I don't want to make it.
No tool prevents failure. Releases break things. Certificates expire, disks fill, dependencies vanish, a provider has a bad afternoon. You will have outages, and you'll have them with excellent monitoring in place.
What you control is duration, and duration has two parts: the time until someone knows, and the time until it's fixed. Monitoring does nothing for the second part. It collapses the first.
That distinction matters more than it sounds, because detection is usually most of the outage. I've written before about a deploy I made on a Friday where one flow broke quietly and stayed broken for thirty-six hours. The actual fix, once I found it, was small — it usually is. Nearly all of that time was not knowing, and then reconstructing a Friday evening from log fragments on a Sunday afternoon with a furious phone call behind me.
The repair was twenty minutes. The outage was a day and a half. Those were the same bug.
Put a number on the half you can change. With CleverQA watching, a dead endpoint is confirmed and alerting within a minute or two on the paid tiers — checks run as often as every 30 seconds, with a configurable number of consecutive failures before it pages you so a single blip doesn't wake anyone. A missed heartbeat is detected within 30 seconds of its deadline, because the sweeper runs continuously rather than on your job's schedule.
So the thirty-six hours becomes minutes, and the twenty-minute fix stays a twenty-minute fix. That's the entire transaction. You're not buying a better repair. You're buying the difference between those two numbers.
Which conversation do you want to have?
And this is where the reputation argument turns around, because it's not really about uptime at all.
Same outage, two versions.
Version one. Your phone rings. It's the CEO, or a customer, or your biggest account. Something is broken, they found out before you did, and now they're telling you about your own system. You say you'll look into it. For the next hour you have nothing to report, because you're still establishing what's wrong. Every update you give is a guess with a caveat on it.
Version two. You message them first. "We had a failure at 21:04 in the payments webhook. It's affecting the receipt emails, not payments themselves. I'm on it, status page is updated, I'll have an update in thirty minutes."
Identical incident. Completely different outcome — and here's the part worth noticing: in version two you come out of it looking more competent than if nothing had happened at all. Not because the outage was good, but because you demonstrated the thing people actually want to believe about you, which isn't that your system never breaks. It's that you're in control of it.
Nobody trusts a system that has never failed. They've never seen it tested. They trust a team that clearly knows what its system is doing.
That's what the tool buys. Not a reputation for never going down — nobody has that and nobody believes anyone who claims it. A reputation for knowing first. And "knowing first" is not a character trait or a work-ethic question. It's a configuration.
Literally a configuration, and it's worth spelling out what version two requires, because every piece of it is a setting rather than a heroic quality:
Something had to wake you at 21:04. Email and SMS, with an escalation policy behind it — tiers that keep paging until somebody acknowledges, so an alert that arrives while you're asleep doesn't simply sit there being correct and unread. If nobody acks the first tier, it moves to the next one.
You had to know which service, not that something was wrong. "The payments webhook, affecting receipt emails, not payments themselves" is a sentence you can only send if the alert named the service and the check that failed. That's the difference between reassuring your biggest customer and alarming them.
The status page had to already say so. Public, with components described in customer language rather than service names, so it's useful to someone who doesn't know your architecture. The reason this matters is timing: during an incident you do not have the attention to write a holding statement, and the ten minutes you'd spend on it are the ten minutes people are forming their opinion.
And it had to become a thing you could point at the next day. A defect with the timeline, the evidence and a first guess at the cause attached, in your tracker. When someone asks on Thursday what happened on Tuesday, the answer exists and you don't have to reconstruct it.
Version one isn't what happens to disorganised people. It's what happens by default. Version two is what happens when somebody spent twenty minutes configuring it in advance.
What a startup actually loses
With the revenue-per-minute numbers set aside, here's what's really on the invoice:
Trust, which is the expensive one. Covered above, unmeasurable, and the reason the rest of this list matters.
The look of being amateur. This is specific and it's worth naming. A big company that goes down is having an incident. A startup that goes down is not ready. Same event, different reading, because people are already uncertain about whether you're a real company and an outage is the kind of evidence they're looking for. It's unfair and it's completely real, and the way you counter it isn't uptime — it's visibly handling it: a status page that says "we know, we're on it," and a human being communicating before anyone has to ask. Amateurs go quiet during incidents. That silence is what reads as amateur, more than the downtime does.
Founder hours, your most expensive and least counted resource. My Sunday was not just a Sunday. It was the most expensive labour in the company, spent on archaeology — reconstructing what happened — rather than on fixing anything. Monitoring doesn't make you better at debugging. It means you start debugging with a timeline instead of a blank page.
This is where I'd put the honest value of the AI part, since every tool in this category now claims some. When a check fails, CleverQA writes up what it thinks happened in plain language — what failed, what the evidence looks like, what to check first, and how confident it is. The last part is the part I care about: when the evidence is thin it says so rather than inventing something authoritative, because a confident wrong answer at the start of a debugging session costs you the afternoon. It's not magic and it won't fix anything. It's a head start on the question "where do I even begin," which on that Sunday was worth more to me than anything else would have been.
The deal that goes quiet. Nobody emails you to say they chose someone else because of the thing they saw in the demo. They just go quiet, and you attribute it to price or timing. You will never get a clean attribution on this, which is exactly why it's easy to keep ignoring.
Churn you can't trace. The user who hit a dead screen during their first session, whose acquisition you paid for, who left without ever telling you why. They don't file a ticket. They were never invested enough to complain.
And the timing multiplies everything
One more thing, and I think it's the most under-appreciated part.
Downtime cost is wildly non-linear in when. Ninety minutes down at 4am on a Tuesday costs you nearly nothing. The same ninety minutes during a demo, a launch, the day an investor is poking around, or the hour after you got written up somewhere, is in a different universe.
So the expected value of monitoring has very little to do with average downtime. It's about the handful of hours a year where being down is genuinely damaging — and you cannot know in advance which hours those are. The investor who looked at your product on a whim. The prospect who tried it at 11pm. The journalist who clicked the link.
That's the real argument for always-on rather than good-enough. Not that every minute is expensive, but that a few of them are enormously expensive and they're indistinguishable from the others until afterwards.
So what's it worth
Concretely, what you're buying is the collapse of the detection half:
Something watching every service, not just the front door. Each endpoint, the background jobs, the certificates, the specific database query that matters, the gRPC service, the six-step checkout flow in a real browser. The hidden service that took down that demo is exactly the kind of thing this is for — it's small, it's forgotten, and a check on it costs nothing to set up and then runs forever.
Heartbeats for the things nothing can probe. Your cron jobs and workers don't serve HTTP, so nothing external can ask them anything. Instead they check in, and silence is the alarm. That cache-refresh job that stopped four months ago would have paged somebody the first night it didn't run. One line appended to the crontab.
An agent that names the service. Not "the box is at 94% memory," which starts a search. payments-worker is at 94% and climbing 6% a minute, which ends one.
Alerts that find you, with escalation if nobody acknowledges. Email, SMS, webhook. The point is not that an alert exists. It's that it doesn't sit unread somewhere until Monday.
A status page, which sounds like the least interesting item on this list and is the one that most directly addresses looking amateur.
And all of it becoming tracked work rather than a notification. A defect with an owner, a status, the evidence attached, and a first guess at the cause, pushed into Jira or Linear or GitHub or Azure DevOps. Notifications scroll away over a weekend. Work items are still there on Monday — and when the thing recovers, the item closes itself, so you're not left with a tracker full of problems that fixed themselves.
Plus a number on each release. 0 to 100, built from uptime, crashes, open defects and load-test results, with a ship-or-hold recommendation. Which is the version of this whole article you can act on at 4pm on a Friday.
The honest limit: none of it would have saved that demo once the service was already dead. Twelve seconds in, an alert arrives, and the panel is still blank. What it would have done is tell somebody four months earlier, the first night that job didn't run, when fixing it was a five-minute job nobody would remember.
That's the actual product. Not heroics during the disaster. The absence of the disaster, because a small thing got caught while it was still small.
So why pay for it
Start with the free plan, because I'd rather tell you where the line is than have you find it.
Free gets you five monitors, checked every five minutes, with alerts by email, one status page, defects, and the AI analysis. That is genuinely enough to catch the entire class of failure this article is about — five checks on five forgotten things, which is roughly how many forgotten things take down demos. If that's all you ever use, that's a fine outcome and it costs nothing.
Here's what you're actually buying when you pay:
More things watched. Five becomes fifty on Essentials and a hundred and fifty on Pro. Five is enough for the critical paths; it is not enough to cover every background job, certificate and endpoint in a real system, and the whole argument of this article is that coverage of the boring things is where the value is.
Faster detection. Five minutes between checks becomes one minute, then thirty seconds. On the free plan a failure can be live for five minutes before anything notices. That's fine for a side project and not fine for something a customer is paying for.
SMS. On the free plan SMS is converted to email. At 2am that's the difference between an alert and a record of an alert.
Escalation policies, on Pro — the tiered paging that makes version two of that conversation possible when the first person doesn't wake up. If you're a team rather than one person, this is the feature that matters most.
Push into your tracker. Defects exist on every plan, but pushing them into Jira, Linear, GitHub or Azure DevOps starts at Essentials. This is the one I'd argue for hardest, because a defect in a tool you don't open every day is a defect you'll forget, and the entire premise is that work persists while notifications evaporate.
More history. Two weeks becomes two months, then six. History is what lets you answer "has this been happening for a while," which is a surprisingly large fraction of real questions.
Unlimited status pages on Pro, if you run more than one product — which, if you're an agency or you ship several things, you do.
Essentials is $60 a month and Pro is $100. For context, that's one tool rather than the four or five separate subscriptions most teams accumulate for this — error tracking, uptime, status page, paging — which tend to add up to more than either of these while still not talking to each other.
And it bears repeating what the comparison is actually against. Not nothing. Against your own time: the Sunday, the archaeology, the demo you have to re-earn. Those are being paid already, irregularly, in the currency you can least afford.
The arithmetic, in the only honest form
I can't tell you what an outage costs you. Anyone who gives you a number for that is selling something, and I'd rather make the comparison you can actually check.
A monitoring subscription is small, fixed, known, and paid in advance. An outage is large, variable, unknown, and billed afterwards in a currency you don't get to choose — usually credibility, sometimes at the worst possible moment.
You're not buying insurance. Insurance pays you back; this doesn't. You're buying a shorter gap between a thing breaking and you knowing about it, which is the only part of the whole equation that a tool can touch, and which turns out to be most of the damage.
The twelve seconds in that demo cost more than a year of watching everything properly would have. That's not a dramatic claim. It's just what a reputation costs to rebuild versus what it costs to protect.
CleverQA watches every service — endpoints, jobs, certificates, hosts — tells you before your customers do, and turns what breaks into tracked work with the evidence attached. Free plan, 5 monitors, no credit card: cleverqa.com