---
title: "What an hour of downtime actually costs you in signups"
description: "An hour of downtime rarely costs an hour of signups. What it costs depends almost entirely on who was trying to visit while it was broken."
url: https://www.fomio.ai/blog/what-an-hour-of-downtime-actually-costs-you-in-signups
published: 2026-09-18T18:00:00.227+00:00
updated: 2026-09-18T18:00:00.227+00:00
topic: consequence
words: 1902
---

# What an hour of downtime actually costs you in signups

The measurable loss is smaller than you fear. The invisible one — the first-time visitor who decided your product doesn't work — is the expensive part.

**In short:**

- You don't lose an hour of signups — you lose the people who arrived during that hour and would have signed up.
- Timing matters far more than length: ten minutes during a launch is worse than three hours at 3am.
- Most of the loss never shows up in your analytics, because people leave quietly and don't tell you.
- The published "downtime costs $X a minute" figures were written for companies with warehouses, not one person with an app.
- The only number you fully control is the gap between it breaking and you finding out.

### Does downtime affect signups?

Yes, but modestly on an average hour and severely on the hours that were meant to matter. You lose the people who arrived while the page was broken, plus a few who would have returned. Divide last month's signups by 720 for a rough hourly figure, then adjust for who was actually visiting.

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[^2]. Earlier survey work in the same vein put the figure at 40% of people for the same three-second wait[^3].

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[^4]. 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[^1].

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[^5]. 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.

- **53%** — of mobile users abandon a site that takes over three seconds to load (Google, reported 2016) [^2]
- **$5,600** — per minute — Gartner's 2014 average cost of downtime, which Gartner called an average only [^1]
- **$137–$427** — per minute — the range IDC puts on small-business outages [^5]

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".

> **Length matters less than timing** — Ten minutes during your launch is worse than three hours at 3am. Always. When you are judging how bad an outage was, look at who was on the other side of it.

## What actually reduces the damage?

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. **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. **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.

**Paste this into your AI tool**

```text
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.

*Ways to be told your app has stopped working*

| Tool | What it's good at | What it asks of you |
| --- | --- | --- |
| UptimeRobot | The default free option, very widely used. Watches a web address and emails you when it stops responding. | Asks how often to check and which kinds of failed reply should count as an outage, and the dashboard assumes you know. |
| Better Stack | Much more polished. Good public status pages, and phone calls and text messages on paid plans. | A serious engineering product, with a serious engineering product's learning curve and pricing. |
| Pingdom | Long established. Checks from many locations worldwide and keeps deep performance history. | Priced for companies rather than for one person with a side project. |
| Uptime Kuma | Free, open source and genuinely excellent. | You host it yourself on a server you maintain. If you're reading this article, that's a real cost, not a footnote. |
| Fomio | Built for people who made an app with an AI tool. Paste a link and it works out what to watch, then reports one of three things: Working, Having trouble, or Down. | Nothing to configure. It tells you by email only — no text messages, no WhatsApp, no Discord. |

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.

## Questions people also ask


### How long is too long for an app to be down?

There's no threshold that makes it fine. What matters is who was visiting. A three-hour outage overnight, with a handful of visitors, costs you almost nothing measurable. Ten minutes on launch morning can cost you the launch. Judge an outage by the traffic it interrupted, not the clock. If you can't tell how much traffic you had, that's the first thing worth fixing.

### Will Google penalise my site for being down for an hour?

A single short outage is not the thing to worry about. The research worth paying attention to is about people, not rankings: more than half of mobile users abandon a site that takes over three seconds to load, according to Google research reported in 2016. If a visitor won't wait three seconds for a slow page, they certainly won't wait out a broken one. Repeated, lengthy outages are a different conversation, and the fix for those is the same — find out sooner.

### Should I apologise to users after downtime?

If people were mid-task when it broke, yes, and keep it short. One honest line about what happened and that it's fixed does more for trust than silence, and far more than a long technical explanation nobody asked for. If it happens often enough that you're apologising monthly, a public page showing whether the app is working saves you writing the same message over and over.

### Can I recover the signups I lost?

Mostly no, because you don't know who they were. That's the point of the unmeasurable loss — those people never entered your records. What you can recover is the ones who were part-way through something and left an email address behind. Reach out to those directly. For everyone else, the only real remedy is making the next outage shorter.


## Sources

[^1]: Calculating the cost of downtime — Atlassian (2026-06-09). https://www.atlassian.com/incident-management/kpis/cost-of-downtime
[^2]: Google: 53% of mobile users abandon sites that take over 3 seconds to load — Marketing Dive (2016-09-12). https://www.marketingdive.com/news/google-53-of-mobile-users-abandon-sites-that-take-over-3-seconds-to-load/426070/
[^3]: Website load time statistics for 2026: Trends & key insights — Hostinger (2026-02-02). https://www.hostinger.com/tutorials/website-load-time-statistics
[^4]: Website Load Time & Speed Statistics: Is Your Site Fast Enough? — WP Rocket (2026-09-01). https://wp-rocket.me/blog/website-load-time-speed-statistics/
[^5]: What an IT Outage Really Costs Your Small Business — CTSI (2026-08-01). https://www.ctsinet.com/blog/cost-of-it-downtime-small-business