Ask a business owner where their website lives and you'll usually get an answer. Ask where their booking system lives, or the portal their customers log into, or the software that tells the drivers where to be at seven tomorrow morning, and the answer gets vaguer. It's on a server. It's in the cloud. It's with a company the previous developer set up and nobody has heard from since. It's somewhere.
I don't say that to be critical. Most of the people I work with are running gyms, holiday parks, law firms and coach companies. They are not supposed to know what a server is, any more than I'm supposed to know how to service a coach. But there is a difference between not knowing the technical detail and not knowing who is responsible, and it's the second one that catches businesses out.
For a brochure site, "somewhere" is fine. If it goes offline for an afternoon you lose a bit of visibility and perhaps a phone call or two. The moment a system is taking bookings, holding customer records or running the daily operation, the same vagueness turns into a risk that has your name attached to it. When that system stops at nine on a Monday morning and the answer from the hosting company is "we're looking into it", you discover very quickly that you never actually had a plan. You had a subscription.
This article is about what hosting a critical system properly actually involves. It's a longer list than most people expect, and very little of it is about the server.
A system doesn't become critical because it's complicated or expensive. It becomes critical because of what happens when it stops. The simplest test I know is to imagine it going dark for a full working day and to write down, honestly, what that costs. Bookings you didn't take. Staff who couldn't do their jobs. Customers ringing the office because the app wasn't working, and the person who answered not being able to tell them anything useful. The quiet reputational cost of looking like a business that can't keep its own systems running.
If writing that list makes you uncomfortable, the system is critical, and it needs to be looked after as though it is. That's true whether it's a large bespoke platform or a modest booking form that happens to be the only way customers can reach you at the weekend. When we build bespoke business systems like the one behind Jones International's coach operation, this is the standard we start from. The software is only half the job. Keeping it running is the other half, and it never finishes.
People picture hosting as a computer in a data centre with their system on it. In practice a live system depends on a chain of things, and every link has to be working for the customer to see anything at all.
There's the server itself, obviously. There's the application running on it, and the database behind that. There's the domain name, which is registered with someone and expires on a date somebody once knew. There's the SSL certificate that makes the padlock appear, which also expires, and has a habit of doing so on a Sunday. There's email delivery, which is its own small world of authentication records and reputation scoring, and which is the reason booking confirmations sometimes land in spam for no visible reason. And there are the third-party services almost every modern system leans on: a payment provider, a mapping API, an SMS gateway, an accounts package.
A failure anywhere along that chain looks identical from the outside. The customer sees an error, or nothing, and they don't care whether the cause was a full disk or a lapsed domain registration. So the real question about hosting is not "where is the server?" but "who owns the whole chain?" If the domain is with one company, the server with another, the email with a third and the certificate was set up by a freelancer three years ago, then the honest answer is that nobody owns it, and you'll find that out at the worst possible moment.
Almost every hosting provider will tell you they monitor your server. What they usually mean is that a script checks whether the machine responds, and raises an alarm if it doesn't. That's useful, but it's a long way from knowing your system works.
"The server is up" and "a customer can complete a booking" are different facts. A server can be perfectly healthy while the database connection has dropped, or the payment provider is timing out, or a change made last week means the confirmation email silently stopped sending. None of those show up on a basic uptime check. They show up when a customer rings.
Proper monitoring for a critical system exercises the journeys that matter. It logs in. It searches. It steps through a booking to the point just before payment. It checks that the emails are actually leaving. And it tells someone, by which I mean a person who can do something about it, before the phone rings rather than after. If your current arrangement relies on a human noticing that something is wrong, then your customers are the monitoring, and they didn't sign up for the job.
I'll give you a real example of why this matters. A while ago one of the servers I look after started running very hot. Nothing was down, and a simple uptime check would have said everything was fine. What was actually happening was that an automated scanner, hunting for leaked credentials, was hammering one client's site with thousands of requests for files that didn't exist. Left alone, it would have slowed every site on that server to a crawl within hours. Because I could see the load climbing and see where it was coming from, I could block the traffic pattern at the web server level, put a broader crawler filter in place, and then move the whole server onto a machine with dedicated processors so a repeat wouldn't have the same effect. None of the clients on that server knew anything had happened, which is exactly as it should be.
Everyone has backups. I have never met a business owner who, asked whether their system was backed up, said no. The problem is that "we have backups" answers the wrong question.
The questions that matter are these. How quickly could the system be brought back if the server disappeared this afternoon? To what point in time: last night, last hour, or last week? Where are the backups kept, and is it somewhere other than the server that's just failed? And when did anybody last actually restore one, to prove that the process works and the files aren't corrupt?
An untested backup is a hope. A tested one is a plan. The difference only becomes visible on the day you need it, which is the one day you can't afford to find out.
The same applies to security, and for the same reason: it's a discipline rather than a task. The operating system, the web server, the database, the language runtime and the libraries your application depends on all release fixes, and they release them constantly. Applying them is not glamorous work. It's a weekly routine of reading what's changed, applying updates, and checking nothing has broken. Skipping it is easy and nothing bad happens immediately, which is precisely how systems age into liabilities. The breach or the outage arrives eighteen months later, tracing back to a fix that was available all along.
Generic hosting support can do generic things. They can reboot a server, check disk space, restart a service. What they cannot do is tell you why bookings stopped confirming at 2pm, because they have never seen your booking system and have no idea how it works.
Application-aware support is different in kind, not just degree. It means the person answering knows your workflows, your integrations and your data. They know that the nightly export to your accounts package runs at 1am and that if it fails, the finance team will notice by ten. They know which third-party service is flaky and which one has never gone down. They can look at an error and recognise it, rather than starting from scratch. That is the difference between a ten-minute fix and a three-day email chain in which you find yourself translating between a hosting company and a developer who no longer works for you.
It also makes change far less nerve-wracking. Deploying an update to a critical system should be a rehearsed, timed event, not a hopeful click. It's tested first on a copy of the live system. It's scheduled around your operation, so it's not going in at the busiest point of your week. And there's a way back if something misbehaves. That's only possible when the people supporting the system are the same people who understand it.
Hosting is almost always compared on price. A few pounds a month here, a few more there. That's the wrong comparison for a critical system, because the monthly fee is the cheapest part of the whole arrangement. The expensive part is the bad day, and the cheapest hosting is precisely the kind that makes the bad day more likely and longer.
The better approach is to match the arrangement to what the system means to your business. That means capacity for your busiest morning rather than your average one. It means documentation, so that if I fell under a bus tomorrow another competent developer could pick up your system and understand it. It means one place to ring, and one person who owns every link in the chain, from the domain renewal to the database. And it means a running record of what has been done: which updates were applied, when the last restore was tested, what changed and why.
That is what our hosting and support service is for. It exists alongside the systems and software we build because a system nobody is properly looking after isn't finished, however good the code is. What you're buying isn't server space. It's accountability.
If you're not entirely sure what your critical system is sitting on, who is responsible for it, or what would happen if it went down tomorrow, that is worth finding out now rather than during the outage. It's usually a few phone calls and an hour of someone's time. It might be reassuring. If it isn't, at least you'll know while there's still time to do something about it.
Got questions? We'd be happy to talk it through with you.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
