What an hour of downtime actually costs you in signups

You refreshed and got nothing. A white screen, or that unhelpful grey page. And now the question underneath all the other questions is the one you can't look up: did that cost me anything?

Here is the useful way to think about it. There are two separate losses from a broken hour, and they behave differently. One you can estimate on the back of an envelope. The other you will never see in a chart.

How do I work out how many signups I lost?

Take your signups over the last thirty days, divide by thirty, then divide by twenty-four. That is your average signups per hour. If it comes out at 0.4, an average broken hour cost you roughly half a signup. If it comes out at twelve, it cost you twelve.

Almost nobody's traffic is flat, though, so that average lies in both directions. An hour at 4am on a Sunday is close to free. An hour on the morning your post is on the front page of somewhere, or the hour your newsletter lands, is not an average hour — it is the hour that was supposed to pay for the whole month.

Two outages of identical length can differ enormously in what they actually cost. So when you are working out whether that hour mattered, don't ask how long it was down. Ask who was coming.

Why don't the lost signups show up in my analytics?

Because people abandon broken pages faster than feels reasonable, and they don't tell you they did. Google's own research, widely reported in 2016, found that more than half of mobile users abandon sites that take longer than three seconds to load². Earlier survey work in the same vein put the figure at 40% of people for the same three-second wait³.

Those numbers are about slowness, not outright failure — but a site that is down is the extreme end of the same curve. Nobody sits on your error screen hitting refresh for five minutes in hope. They hit back, and they're gone.

The part that stings more is how ordinary this is from the visitor's side. Survey work on mobile frustrations found around half of mobile users report running into error messages, 45% broken functionality, and 38% a site simply being unavailable⁴. They have seen it a hundred times on other people's sites. They don't file a bug report. They form a quiet, unexamined opinion — "that thing didn't work" — and move on.

So the honest answer is: slightly more than your analytics will ever show you. The people who bounced off a broken page mostly don't appear anywhere as a lost conversion. They appear as traffic that didn't convert, on a day you may not even remember was a bad day.

What about the "downtime costs $X per minute" figures?

Mostly ignore them. They were written for companies with warehouses and call centres. The standard reference point is a 2014 Gartner figure of $5,600 per minute of downtime, which Gartner itself flagged as no more than an average¹.

The small-business version of the same kind of research estimates the damage at somewhere between 137 and 427 dollars for each minute the business is unable to operate⁵. Even that lower figure assumes staff sitting idle, phone lines unanswered, orders not being taken. If you are one person with an app and a day job, most of those cost components are simply zero for you.

What these figures are genuinely good for is scale, not precision. The industry treats an outage as expensive because for most businesses it is. Yours is cheaper per minute than theirs. It is not free.

When does an hour of downtime really hurt?

When people were inside your app doing something — mid-signup, mid-checkout, mid-upload. The damage is disproportionate then, not because of the hour, but because their last experience of your product is it failing while they were trying to give you something.

First-time visitors are the most fragile group. They have no stock of goodwill with you. A returning user who has had a good month will shrug and come back after dinner. Somebody who clicked your link for the first time ever, at the exact wrong moment, has now formed their whole impression of your product, and it is "broken".

What actually reduces the damage?

1. 1
   Know it's broken before your users do

   This is the whole game. The difference between a ten-minute outage and a six-hour one is almost never how hard the fix was — it's how long it sat there while you were asleep, at dinner, or in a meeting. Most builders find out because a user messages them, which means the damage has already happened.
2. 2
   Say something while it's broken

   Even one line — "we're having trouble, back shortly" — turns "this product is broken" into "this product has a person behind it". It costs nothing and it protects the impression, which is the expensive part.
3. 3
   Fix the recurring cause, not just the incident

   If it has gone down three times this month at roughly the same time of day, that is not bad luck, it is a pattern. Hosting limits, a database that has hit its ceiling, something scheduled that falls over.

My app went down for about an hour today and I don't know why. Walk me through the most likely causes given how this app is hosted and what it depends on, check for anything that runs on a schedule or any limit we might be hitting, and tell me what to change so it fails more gracefully next time instead of showing a blank page.

What are the ways to find out my app is down?

Something outside your app has to visit it regularly and tell you when it stops answering. Most of the well-known options were built for people who do this for a living, and they read like it. Here is a fair look.

When something breaks, Fomio explains in plain language what likely went wrong, and on the paid plans it writes a prompt you can paste straight into the tool you built the app with. The free plan watches one app from outside, checks every five minutes, emails you when it breaks, keeps seven days of history, and needs no card. Builder covers three apps, checks every minute and adds the fix prompts. Pro covers fifteen, adds a public status page for your users and a year of history. Current prices are on fomio.ai/pricing.

Where the others are genuinely better: Pingdom and Better Stack check from more places around the world, keep deeper performance data, and can phone or text you. If being woken at 3am by a ringing phone is a requirement, take one of them. If what you want is to stop finding out from a user at lunchtime, the appeal of the plain-English version is that it doesn't ask you to understand anything first.

So what should I do about it?

You can't prevent every outage. Nobody can — the platforms you are built on go down too. What you can change is the gap between it breaking and you knowing.

Set up something today that visits your app on a schedule and emails you when it stops answering, then go back to building. Shrinking that gap from six hours to five minutes does more for your signups than anything else on this list.