Can You Afford the Downtime? What a Broken Website Really Costs You

It always happens on a Friday

Nobody schedules downtime. It arrives on a Friday afternoon, or during your busiest trading week, or twenty minutes before a campaign email lands in four thousand inboxes.

The site is down. Or the contact form has quietly stopped sending. Or the booking page throws an error that nobody can reproduce on their own phone. And the question that follows is always the same: who fixes this, and how long is it going to take?

For a great many small businesses, the honest answer is "me, and I have absolutely no idea."

That is the moment worth thinking about now, while nothing is on fire. Because the cost of downtime is never really the downtime. It is everything that happens around it.

The arithmetic of an outage

Start with the obvious part. If your website generates enquiries, bookings, or sales, an outage is a direct hole in the day.

Take a business turning over £500,000 a year with a website that meaningfully contributes to, say, half of it. That is roughly £1,000 of website-influenced revenue on an average working day. A site down for six hours on a busy Tuesday is not a rounding error.

For an e-commerce or booking-led business, it is sharper still, because the traffic does not wait. A visitor who hits an error page does not make a note to come back later. They go to the next result, and they buy there.

Then add the part that is harder to invoice:

• The paid traffic you are still funding. Ads keep running and keep charging while the landing page 500s. You pay for every click into a broken site.
• The campaign you just sent. An email or social push into a dead site does not get rescheduled, it gets wasted.
• The search damage. Repeated outages and slow recovery are a signal to search engines. Rankings built over years can soften over weeks.
• The trust damage. A prospect who sees a security warning or a half-loaded page does not conclude that your hosting is having a bad day. They conclude something about your business.

But the real cost is the hunt

Here is the part that catches owners out. The outage is rarely the expensive bit. The troubleshooting is.

When a site breaks and there is no one whose job it is to fix it, a very predictable sequence begins.

You check whether it is just you. You ask a colleague to check. You try a different browser, then your phone on mobile data. You log into the hosting panel and find nothing obviously wrong. You search the error message and read three forum threads from 2019. You find the email address of the developer who built it, four years ago. You email them. You wait.

Meanwhile the phone is still ringing, the day's actual work is still waiting, and the site is still down.

Even a modest incident routinely eats three to six hours of someone's day, and that someone is usually the owner or the most capable person in the building. At £75 an hour of diverted capacity, a single afternoon of this is £300 to £450 of value spent achieving nothing. Two or three incidents a year, plus the smaller weekly friction, and you are into four figures of time before anyone has been paid to actually repair anything.

Then there is the emergency rate. Finding a freelance developer at short notice, out of hours, with no prior knowledge of your site, is the most expensive way in the world to buy technical help. They have to understand the system before they can fix it, and you pay for both.

What actually goes wrong, in the real world

These are not hypotheticals. They are the recurring patterns behind most small business website emergencies.

The WordPress update that ate the site

A routine plugin update runs overnight. It conflicts with the theme, or with another plugin, or with the PHP version the host quietly upgraded last month. The site returns a white screen. There is no error message worth reading because error display is switched off in production.

The fix requires knowing which plugin, rolling it back, and having a backup recent enough to matter. The average WordPress site runs 20 to 30 plugins from a dozen different authors, each updating on its own schedule, none of them tested against your particular combination. The surprise is not that it breaks. It is that it holds together as often as it does.

The certificate nobody was watching

An SSL certificate expires. Every browser now throws a full-screen security warning in front of every visitor. The site is technically up and commercially dead.

This one is getting worse, not better. Certificate validity periods are shrinking from 13 months today toward 47 days by 2029, which means renewals move from an annual afterthought to something closer to a monthly operational task. Manual renewal was already a bad habit. It is about to become an untenable one.

The domain that lapsed

The renewal email went to an address nobody monitors, or to a former employee, or the card on file expired. The domain lapses. Website gone, and email gone with it, which is the part that turns an inconvenience into a genuine crisis.

Recovery is possible but rarely quick, and the business spends the interim unable to send a quote or receive an enquiry.

The Wix or Squarespace site that is up but broken

This is the quiet one, and it is the most common of all. The site loads perfectly. Nothing alerts, because nothing is technically down.

But the contact form has been posting to an address that stopped existing when someone left. Or a form notification has been routing to spam since a mail provider tightened its rules. Or a third-party booking widget updated its embed code and now silently fails on iOS.

Businesses have lost months of enquiries this way and only discovered it when a customer rang to ask why nobody got back to them. There is no outage alert for "working, but not doing its job."

The legacy site whose developer has moved on

The site was built in 2017 by someone competent who has since changed careers, moved abroad, or simply stopped replying. There is no documentation. Nobody knows where it is hosted, who owns the domain registration, or what the database credentials are.

Everything works until the day it doesn't, and then the cost of the fix includes an archaeology project. In the worst cases, the honest recommendation is a rebuild, because reverse-engineering the original is more expensive than starting again.

The traffic spike that took you offline

Some good news arrives. A local paper covers you, a post performs, a supplier links to you. Traffic multiplies, shared hosting buckles, and your site goes down at the exact moment the largest audience you have ever had is trying to look at it.

The best day of your year becomes the most expensive.

The common thread

Look across all of them and the pattern is not really technical. It is structural.

• Nobody is watching. Most small business sites have no uptime monitoring at all. The alert system is a customer being kind enough to ring you.
• Nobody owns it. Responsibility is spread across a host, a builder, a freelancer, and you. When something breaks, the first hour goes on working out whose problem it is.
• The surface area is enormous. Plugins, themes, databases, PHP versions, third-party embeds, and DNS records. Every one of them is a moving part maintained by someone else.
• Backups are assumed rather than tested. "The host does backups" is a belief, not a plan, until the day you need a restore and discover the retention window was seven days.
• Recovery depends on one person's memory. And that person is frequently unavailable, or no longer works with you.
• Failure is often silent. The most damaging problems never trigger an alarm.

None of that is fixed by being more careful. It is fixed by changing who is responsible and how the site is built in the first place.

How Aliora Managed Services takes it off your desk

The simplest way to put it: with Aliora, downtime stops being your problem to notice, diagnose, or solve.

That happens in two ways. The first is architectural, and it is the part that quietly removes most of the failure modes before they can occur.

Aliora sites are built on a modern headless architecture with Sanity as the content layer, served from a global edge network. In practical terms:

• There are no plugins to conflict. The single largest cause of small business site failure simply does not exist as a category.
• There is no database or server for you to maintain. Pages are served as pre-built files from an edge network, not assembled on demand by a server that can fall over.
• Traffic spikes are a non-event. Edge delivery scales without anyone being paged. Your best day stays your best day.
• Every change is versioned. If something does go wrong, rolling back is a deliberate, immediate action, not an archaeology dig through backups.
• SSL, certificates, DNS, and infrastructure are handled as a matter of course, including the renewal cadence that is about to get considerably more demanding.

The second is operational, and it is the part that matters at 4pm on a Friday.

• The site is monitored continuously, so problems surface to us before they surface to your customers.
• Forms, integrations, and the things that fail silently are checked, because "up" is not the same as "working."
• Security patching and dependency updates happen on our schedule, tested, not pushed blindly into production overnight.
• Performance and Core Web Vitals are watched continuously, so slow degradation gets caught while it is still slow degradation.
• You have one email address and a support tracker. Send the request, see where it is, see when it is done.
• You have a named Service Lead who already knows your business, your site, and your priorities. No triage, no explaining the history, no waiting while someone gets up to speed.

And crucially, none of this arrives as an emergency invoice. It is included in the monthly figure, from £195 a month, because it is the job rather than an exception to it.

The comparison that matters

Doing it yourself: unlimited liability on your own time. One bad afternoon costs you several hundred pounds of diverted capacity and achieves nothing, and you carry the anxiety of not knowing whether it will happen again next week.

Calling someone when it breaks: emergency rates, no prior knowledge of your site, and a wait that runs from hours to days. You pay for the diagnosis and the fix, every single time, and nothing is done to prevent the next one.

A cheap hosting package with "support": a ticket queue that will tell you, correctly and unhelpfully, that the server is fine and the problem is in your application.

Aliora Managed Services: an architecture with most of the failure modes designed out, monitoring that catches what is left, and a named person who fixes it before you have finished reading about it. Predictable monthly cost. No incident invoices.

The difference is not that we are faster at emergencies. It is that there are dramatically fewer of them, and they are not yours to manage.

You keep control, as always

Handing over responsibility is not the same as handing over access. Because Aliora sites are built on Sanity, your content stays structured, portable, and yours. You can log in and edit whenever you want to, and you could hand the whole thing to another supplier tomorrow if you ever chose to.

What you are giving up is the 9pm troubleshooting, not the keys.

The bottom line

Ask yourself two questions, honestly.

If your website went down tomorrow morning, how long would it take you to find out? And once you knew, who would you call?

If either answer involves a pause, a shrug, or a name you are not sure still works in the industry, you are carrying a risk that is quietly priced into your business already. You just pay it in irregular, unpredictable lumps: a lost afternoon here, an emergency invoice there, a month of enquiries that never arrived.

Aliora Managed Services replaces that with a monthly figure, an email address, a support tracker, and a Service Lead who knows your name. The site is built so that less can break, watched so that what does break is caught early, and fixed without you having to notice.

You cannot afford website downtime. The good news is that you no longer have to be the one dealing with it.