Uptime and server monitoring: spotting failures before your customers do

A webshop that stops responding at 08.57 in the morning. A customer portal that turns sluggish around midday. An integration with the accounting system that quietly stops pushing orders through. For the person on the other end, the technical cause is irrelevant: it works, or it doesn't.

Most of the outages we get called about did not come out of nowhere. There were signals. Either nobody was watching, or the alert landed in an inbox that hadn't been read in months. This guide is about closing that gap, so you know what is going on before your phone starts ringing.

Uptime isn't a number you run into once a quarter in a report. It's a promise to customers, colleagues and partners. If your organisation runs day to day on a platform, an internal application or an integration with an outside party, you want to be the first to know when something starts to slip.

What uptime really tells you about your service

Uptime is the time a system is available and usable. That second word tends to get skipped. A server can answer every request it receives while checkout in the webshop breaks on the payment provider. An internal tool can open perfectly well and still be unusable, simply because every page takes fourteen seconds.

So it pays to look at availability from the position of whoever has to work with it. Does the page load? Can someone log in? Does the order arrive at the other end? Is the application still exchanging data with the supplier's system? Which of those questions weighs heaviest differs per organisation. A publisher wants articles live at exactly the moment traffic peaks. A SaaS platform can't go an hour without login and data processing. For a wholesaler, the chain from stock to order to logistics is usually the weakest link.

A high uptime guarantee is therefore only worth something once it's clear what is being measured. 99.9 percent sounds close to perfect and still amounts to almost nine hours of downtime a year. Whether that's acceptable depends on your opening hours, your processes and what an hour of standstill genuinely costs you. For a brochure site it's an inconvenience. For an order portal on a Monday morning it's something else entirely.

Monitoring in layers: looking past up or down

Useful monitoring is built from a few layers that complement each other. The outer layer checks whether a service can be reached from outside: the website, an API endpoint, the mail server, the login page. That's the layer that tells you fastest what your customers are experiencing.

External reachability doesn't explain why something goes wrong, though. For that you look at the machine underneath: processor load, memory use, free disk space, network traffic and processes that have quietly stopped. A disk filling up over three weeks produces no complaints today. Next week that same disk blocks your database writes, your uploads and your nightly backups in one go.

On top of the infrastructure sits the application, and that's where it gets interesting. Here you test whether the things that cost money or time actually succeed. A server can be in perfect health while a database connection fails, the payment provider starts timing out, or last night's scheduled import gets stuck halfway. Checks like these are the difference between monitoring for the technical record and monitoring your management team can act on.

Then there's logging, which usually gets attention only once it's too late. Monitoring reports that something is broken. Logs tell you why. Error messages, outliers in response times and failed jobs are the material an administrator uses to find the cause in minutes rather than hours. Without it, recovery turns into guesswork, and that guessing takes longer the more systems and third parties are involved.

Which signals deserve immediate attention?

Not every alert needs to pull someone out of bed at three in the morning. Do it anyway and within a month you have alert fatigue: so much comes in that nobody looks any more, and the alert that genuinely mattered slides down the list with the rest.

Critical is whatever is costing money or trust right now: a production environment nobody can reach, a database falling over, an expired SSL certificate, a full disk, an integration leaving orders untouched. A warning is something moving in the wrong direction: memory use creeping up a little every week, response times doubling, a backup that used to take twenty minutes and now takes two hours. Nobody needs to wake up for those, and they shouldn't sit untouched either.

Beyond that, don't leave thresholds on their default setting. A server that hits its ceiling every morning between eight and nine might just be a server doing its job. That exact same spike on a Sunday evening is a signal: a bug in the software, traffic that has no business being there, or a process stuck in a loop. Monitoring becomes useful the moment you put the numbers next to the normal rhythm of your business.

Availability starts with clear ownership

During an outage, ambiguity is the most expensive thing you have. Who receives the alert? Who decides how bad it is? Who is actually allowed onto the server, who can change the application, and who picks up the phone to call the external supplier? When development, hosting and management are split across three parties, the first half hour often goes on working out whose turn it is.

One party doing everything isn't the only way to solve that. Every part having an owner, agreed in advance, is the part that matters. Write down which systems are under management, which response time belongs to which type of incident, and who keeps customers and colleagues informed while the fix is in progress. An alert that fires with nobody reachable to act on it isn't monitoring. It's a record of an outage.

In practice, splitting incidents into three levels works well. Complete failure or a security risk: pick it up now, whatever the hour. An important function that doesn't work: assess and fix within the agreed response time. Small deviations: schedule them, unless they're demonstrably getting worse. That split saves you a discussion at exactly the moment you can least afford one.

Measuring only helps if you act on it

A dashboard full of green blocks feels reassuring and does nothing else, as long as nobody reads the trend. So go through the recurring warnings periodically, once a month is plenty: where were the peaks, which processes are getting slower, which incident has just come round for the third time? An outage you fix temporarily every month isn't an outage any more. It's a structural problem with a convenient patch on it.

Look ahead at capacity as well. Growth in visitors, orders, files or users rarely translates neatly into load. A ten percent increase can push one badly written query, a search function or an integration over the edge. With custom software it's worth measuring performance before a campaign goes live, rather than during it.

Backups belong to the same management discipline. A green tick next to 'backup successful' says less than you'd hope. You want to know whether the backup is complete, whether a copy sits in a separate location, and when a restore was last genuinely tested. Uptime is about staying available. Recoverability decides how long a really bad day lasts.

Match monitoring to your risk

Not every environment needs the same setup. A company website is well served by reachability checks, an eye on the certificate and basic server monitoring. An e-commerce environment needs checks on checkout, payments, stock integrations and performance under load on top of that. With a SaaS product, user flows, background jobs, databases and APIs are usually all critical, and then the question isn't whether you monitor but how finely.

More checks don't automatically mean better, incidentally. Every one should answer a question you can write down: which business risk does this let us see sooner, and who does what when it fires? If that answer stays blank, you're mostly adding noise. Start with the processes tied directly to revenue, service or daily operations, and build out from there.

The hosting environment weighs in too. Shared infrastructure is fine for predictable traffic and limited risk. Once you're dealing with sensitive data, heavy integrations or hard availability commitments, you want more grip on capacity, security and configuration. That choice follows from how dependent you are, not from a standard package.

From incident to structural improvement

The moment everything is running again, the urge to get on with the day is strong. Understandable, and that's precisely when the one question that actually pays off is on the table: why didn't we see this sooner? A review doesn't have to be a report. Half a page covering what the user noticed, when it started, which signals came first, how it was resolved and which measure makes a repeat less likely is enough.

Sometimes that measure is technical: optimise a query, add capacity, adjust a timeout. More often than you'd expect it sits in the process. An escalation path nobody knew about. A contract with an external service that had quietly lapsed. A change that went to production on a Friday afternoon without review. Both sides deserve attention, because technology is only reliable when the management around it holds up.

Having development and hosting under one roof helps us at moments like that. Not because it's the only workable setup, but because nobody has to wait for another party to call back before deciding whether the problem sits in the code or in the infrastructure.

So don't start by picking a tool. Start with one question: which digital process cannot stop tomorrow? Aim your checks, your alerts and your agreements at that. Then monitoring stops being a technical side issue and becomes the reason your organisation keeps working on the day something goes wrong.