Who notices first when your service goes down – you or your vendor?
Require your hosting vendor to catch failures with automatic alerts, not through complaining customers. The foundation is monitoring uptime, error rates, response times, and the critical business flows, an on-call chain with designated ownership outside office hours too, and an incident process that gives you status updates as it happens and documented learning afterward.
There are two ways to find out your service is down. Either an alert goes off at your hosting provider, or an angry customer calls you. The difference between those two is the entire point of professional hosting, and it’s worth specifying before you sign a contract. Here’s what to require.
Baseline monitoring: what should be measured
Monitoring starts with four things that should always be watched, regardless of what your service looks like.
- Uptime. Does the service respond at all? Measured from the outside, the way a user experiences it – not just whether the server is powered on.
- Errors. What share of requests fail? A rising error rate is often the first signal that something is about to break.
- Response times. How fast does the service respond? A page that loads slowly is, for the user, almost as bad as one that doesn’t load at all.
- Critical flows. The business actions that must not fail: login, orders, payment. A server can look healthy in the statistics while the checkout itself is broken.
The last point is the one that’s most often missing. Basic technical monitoring tells you the server is alive, not that customers can actually shop. Require that the flows where your business actually makes money be watched as their own metrics.
The on-call chain: who responds, and when?
Monitoring without alerting is just graphs nobody looks at at three in the morning. What matters is what happens when a value crosses a threshold.
An on-call chain determines who gets contacted, in what order, and what happens if no one responds. An on-call responder gets the alert first; if they don’t respond within a set time, it escalates to the next level. The requirement is simple to state but easy to forget: there must be designated, staffed ownership outside office hours too. Evenings, weekends, and holidays are exactly when an unwatched outage has time to do the most damage.
Watch out for hosting that “works because Anna usually checks.” Ownership that rests on one helpful individual isn’t ownership – it’s luck, and the luck runs out when Anna is on vacation.
A scenario: the night before Saturday
Imagine payments stop working at midnight ahead of a big sales weekend. In the immature version, it’s not discovered until around nine on Monday, when support fills up with emails from customers who couldn’t complete their purchase. Nine hours of lost sales, and a loss of trust that doesn’t show up in any log.
In the mature version, an alert fires within minutes: the error rate for the payment flow spikes. The on-call responder gets a message, sees a third-party service responding with errors, and temporarily reroutes payments. Customers notice a brief disruption instead of a whole weekend. Same failure, two completely different outcomes – and what separates them is alerting and a staffed chain.
The incident process: during and after
When something does happen, quality comes down to two things: being kept informed while it’s happening, and the failure leading to learning afterward.
| Part of the process | What to require |
|---|---|
| Status updates | Ongoing updates on what's happening and expected time to fix – not silence |
| Response and escalation | Clear ownership of the incident until it's resolved |
| Post-mortem | A documented review afterward: cause and what's changing |
During an incident, you don’t want to be chasing answers. Require your vendor to actively communicate status and an estimated time, so you can manage your own customers. Silence during an outage is almost as bad as the outage itself.
Afterward comes what separates a mature vendor from one that just puts out fires: a post-mortem. A factual review of what happened, why, and what’s changing – without scapegoating. Without that habit, the same failure recurs again and again, and you pay for the same fire multiple times.
How to use this
You don’t need to know how to set up monitoring yourself. You need to ask four questions before you sign: What’s monitored, including our critical flows? What does the on-call chain look like outside office hours? How are we kept informed during an incident? And do you do post-mortems? The answers quickly reveal whether the hosting is well thought out or improvised.
If you’d like help formulating hosting requirements or reviewing a setup, we at Weapp are glad to include it in the systems work. Get in touch and we’ll go through what’s reasonable for your service.
Frequently asked questions
What's the difference between monitoring and alerting?
Monitoring is measuring how the service is doing – uptime, errors, response times. Alerting is someone or something reacting when a metric crosses a threshold. Monitoring without alerting is just pretty graphs nobody looks at when it matters. It's the alerts, with clear thresholds and recipients, that make sure failures are actually caught in time.
What is meant by an on-call chain?
A predetermined order for who gets contacted when an alert fires, and what happens if that person doesn't respond. First an on-call responder, then an escalation to the next level after a set time. The point is that no alert should be able to land with someone who's off duty without moving forward to someone who can act.
What should we require for outages outside office hours?
That there's designated ownership even on evenings, weekends, and holidays – not that alerts pile up until the next business day. What response time is reasonable depends on how business-critical the service is, but the ownership should be staffed and contractual, not something that happens to work because one developer is helpful.
What is a post-mortem, and why does it matter?
A review after an incident that describes what happened, why, and what needs to change so it doesn't repeat – without pointing fingers. It ensures the same failure doesn't recur over and over. A hosting vendor that lacks this habit tends to put out the same fire again and again.
What are critical flows, and why are they monitored separately?
The specific actions where your business makes money or delivers value: customers being able to log in, place an order, complete a payment. A server can look healthy in the statistics while the checkout itself is broken. That's why basic technical monitoring isn't enough – the business-critical flows need to be watched as the distinct metrics they are.