What Downtime Actually Costs When You Manage Client Websites

Let's talk about what downtime actually costs when you run an agency and manage other people's websites. Not the "$5,600 per hour" figure Gartner quotes for enterprise e-commerce. The real number. The one that never shows up in a dashboard.

The phone call you never want

Picture it. Tuesday, 10 AM, you're in a standup. Your phone buzzes. A client.

"Hey, one of our customers just told us the site's down. How long has this been going on?"

You check. Forty-seven minutes. Nobody on your team noticed.

The direct cost of those 47 minutes is usually small. Brochure site? Maybe zero. A shop doing €50K a month? Maybe €40. Annoying, not catastrophic.

The real cost is buried in the subtext: your client learned about a problem with their own website from a customer, not from you. That's the moment the relationship shifts. You stop being the partner who's on top of things and become the vendor who missed something. And that perception sticks around long after the site is back up.

Trust compounds, both ways

Trust behaves like compound interest. Catch a problem before the client notices and it ticks up a little. Let them find out from someone else and it drops a lot. I've watched this play out dozens of times:

1. Client's site goes down. They hear about it from their customer.
2. You scramble, fix it, send the apologetic write-up.
3. Client replies "no worries, thanks for sorting it."
4. Internally, they start wondering what else you're not watching.
5. Six months later, at renewal, they're quietly collecting proposals from other agencies, not because of that one incident but because of the story they've told themselves about your reliability ever since.

Nobody calls to say "I'm slowly losing confidence in your team." They just don't renew.

The monitoring stack that doesn't actually work

Most agencies I talk to already have some monitoring. The problem isn't a total absence of it. It's that they've collected three to five tools over the years and none of them talk to each other.

Uptime Robot watches the homepage. Some SSL checker emails a shared inbox nobody reads. Cron "monitoring" is "we'll notice if the backup email stops showing up." DNS monitoring doesn't exist. Lighthouse got checked once at launch and never again.

What you end up with looks like monitoring but is full of holes. And the holes are exactly where the painful incidents live: the cert that expired silently, the MX record deleted during a domain transfer, the cron job that's been failing for two weeks.

What actually works

The agencies I've seen get this right (the ones whose clients stay for years and never question the retainer) do one thing differently. They know about problems before their clients do.

That's the whole secret. When a client's site goes down at 2 AM, you've fixed it by 7, and your summary is already in their inbox before they've opened the laptop. That builds an enormous amount of trust. You become the team that's always watching.

The practical requirements:

• Checks every 1-2 minutes. Five-minute intervals mean up to five minutes of downtime nobody saw.
• Multi-region verification, so a network blip in one location doesn't wake you.
• SSL, DNS and cron monitoring alongside uptime. The things you don't check for are the ones that bite.
• One alert channel, not four. Split your alerts across four places and one will get muted on a Saturday.
• Escalation: if the on-call person doesn't answer in 15 minutes, someone else gets paged.

You can stitch this together from separate tools. We did, for years. It works right up until it doesn't. Usually the Saturday the SSL alert lands in the wrong Slack channel. Or you run it from one tool. That's why I built Hoppla.

I'll be honest about the boundary: this is monitoring, not an APM. No traces, no flame graphs. Hoppla tells you a client's checkout is throwing 502s and which region confirmed it, not which database query is slow. For knowing about problems before your client does, that's exactly the job. For profiling a slow request, reach for something else.

The upside nobody mentions

Here's what I didn't expect: good monitoring reduces the time you spend on client issues. Not just the 2 AM firefighting, the routine stuff too.

With proper monitoring you stop doing manual checks. You stop opening browser tabs after every deploy to confirm the site came back. "Check SSL certs" comes off the quarterly task list. The system watches everything, all the time, and only bothers you when something genuinely needs you.

The agencies that get this right don't spend more time on monitoring. They spend dramatically less, and the hours go back into real client work.

If you manage client sites and you're still duct-taping monitoring tools together (or not monitoring at all), fixing this is probably the highest-ROI thing you'll do this week. Two minutes per site to set up. The first time it catches something before your client does, it's paid for itself.