Set up monitoring that alerts you when it counts
At 2 a.m. the webshop stops processing orders. The server responds, the uptime check is green and nobody gets an alert. Only when customers ask in the morning where their order confirmation is does someone take a look. In hindsight it was almost always visible: nothing was being measured where things broke, or the one important warning disappeared among a hundred others. Setting up monitoring therefore means solving two things at once. You measure what the customer notices, and you only send an alert when someone actually has to act.
Start with the process that costs money
First pick the process that must not fail. The tool follows from that. For a webshop it is usually the route from product page to payment and order confirmation. For a SaaS platform, login, availability, response time and data processing matter more. For an agency, a client environment or a scheduled data import may carry the biggest impact.
Map that chain, because it is always longer than the website. DNS, hosting, application, database, payment provider, API integrations, queue workers and email delivery all belong to it. If one link falters, the customer gets stuck while your server is perfectly reachable.
Write down one standard per chain, in the language of the business. An order is processed within two minutes. A customer can always log in. The import is finished before 08:00. Sentences like these keep the technical team away from numbers that make little difference to the business, and they tell you exactly what you need to measure.
Set up monitoring from the outside in
Measure what a user experiences first, and only then the components that deliver that experience. A green server means little when the checkout throws an error.
Build one synthetic check first
An external availability check tells you whether a page or endpoint responds. A synthetic check goes further: it automatically performs a real action, such as logging in, adding a product to the basket or submitting a form. That catches problems with sessions, certificates, JavaScript or dependencies that a ping never sees. If you have to choose where to begin, begin with this check on your most important process.
Keep the number small. Testing every button every minute mostly produces maintenance. Pick the few actions whose failure costs money straight away, blocks work or hurts your reputation. If your audience is international, measure from several locations. For a Dutch B2B environment, a measuring point in the Netherlands or Western Europe is usually enough.
Watch trends in the technical layers
Underneath the user journey you measure five kinds of signals:
- Availability of servers, containers, databases and important API endpoints.
- Capacity: CPU, memory, disk space and network traffic.
- Performance: load times, database queries, error rates and queues.
- Application errors, such as exceptions, failed background jobs and faulty deployments.
- Security and continuity: expiring certificates, failed backups and unusual login attempts.
A CPU spike of 90 percent lasting ten seconds can be ignored. A database that keeps getting slower while time-outs climb needs action. So look at duration, trend and the combination of signals. A single CPU threshold mostly produces noise at night, and that is not worth waking anyone for outside office hours.
Give integrations their own check
Many problems start outside the visible website. An integration with ERP, CRM, PIM, accounting or a carrier can fail while the application stays online. Orders get stuck, stock levels drift or customers never receive a confirmation.
For each integration, measure the number of successful and failed actions, the processing time and above all the age of the last successful run. For scheduled jobs that last check gives the best return on effort: did this job actually run within the agreed time? A scheduler that is running but produces nothing useful looks healthy on every dashboard.
An alert should make someone act
An alert is a technical signal. An incident is a disruption that requires action. Forward everything, from every server, log line and short spike, and after a while nobody takes the alerts seriously any more. That alert fatigue creeps in faster than most teams expect.
A useful alert says what is affected, how serious it is and what the recipient should do now. ‘CPU high’ is a useless call at 2 a.m. ‘Checkout API returning more than 10 percent errors for five minutes, orders may fail’ is a reason to get out of bed.
Agree on severity levels before anything goes wrong. Critical goes straight to a reachable person, because an important process has stopped. A warning gets assessed during working hours. Informational events stay in a dashboard or report.
Add a recheck as well. One failed request is usually noise, whereas three failed checks in a row with a rising error rate deserve attention. This is where the real trade-off sits: every minute of waiting makes your alerts more reliable and your response slower. For payments, security and possible data loss you do not want to give those minutes away, so alert immediately there. For everything else, a calm team is worth more than a few minutes gained.
Each dashboard answers one question
An operational dashboard shows whether critical services work and where an incident is. A capacity dashboard shows growth, bottlenecks and future investments. A management overview translates technology into availability, transactions and agreed service levels. Try to fit all three on one screen and the screen answers none of them.
Ten clear graphs are worth more than fifty that nobody looks at. Use a fixed time period and put context on screen, such as deployments, peak load and outages at external suppliers. Without those markers a deviation looks mysterious while the cause is already known.
Metrics, logs and tracing each do their own job. Metrics tell you something is wrong, for example a rising error rate. Logs lead you to the error message and the user or order involved. Tracing shows where a request loses time between application, database and external API. For a simple website you can skip tracing. For a platform with multiple services and integrations it pays for itself in time saved searching.
Who picks up the alert at 2 a.m.?
If you work with a developer, a hosting party, an external SaaS supplier and an internal product owner, everyone sees the same problem and nobody feels they own the fix. That costs time in every outage.
For each critical service, record who the first point of contact is, who has technical access and when to escalate. Attach a short runbook of a few lines to the alert: check this dependency first, only restart this service after consulting someone, temporarily put new orders in a queue. Nobody reads a thick manual during an outage anyway.
Then test whether the alert arrives. An emergency number that has never been tested, an expired token for the messaging service or a mailbox nobody reads, and your best monitoring is shouting into the void. Schedule a regular drill with a test alert or a controlled outage.
Every outage should produce a better check
After an outage you fix the immediate fault first. Then ask why the problem was not visible earlier, whether the alert was picked up and what information you were missing while investigating.
Sometimes the answer is an extra check. Just as often an unnecessary alert has to go. Perhaps context about a deployment was missing, a threshold was set too tight or an external supplier turns out to be a single point of failure. Treat monitoring as part of your technical service, not as a one-off configuration.
That cycle runs faster when development, hosting and management sit close together. Whoever makes a change can then see straight away what it does in production and adjust before customers are affected.
Start this week with your busiest process. Write down the standard, for example ‘an order is processed within two minutes’, and find the check that fires when that standard is missed. If you cannot find one, you know what your first alert will be.