The worst way to learn a service is down is a phone call from a customer. The second worst is an alert delivered to a channel that receives two hundred messages a day and that nobody reads any more. Monitoring is not a tooling problem, because the good tools are free and mature. It is a problem of deciding what genuinely matters and alerting only on that.
What we monitor and why
We build in three layers. Infrastructure covers resource utilisation, disk capacity, hardware health and network reachability. The application layer covers error rates, response time distributions, queue depth and the health of external dependencies. The third layer, the most useful and the most frequently missing, tracks business signals: orders placed per minute, successful logins, payments processed. A sudden drop in orders detects a real problem faster than any technical metric, because it measures the effect rather than a possible cause.
Response times are tracked as percentiles rather than averages. An average hides exactly the users who are suffering: if ninety percent of requests complete in fifty milliseconds and five percent take eight seconds, the average still looks acceptable while a meaningful share of your customers are having a bad time.
Alerts worth waking up for
An alert should mean a human needs to act now. Anything else belongs on a dashboard or in a weekly report. We alert on user-visible symptoms rather than on possible causes: a rising HTTP error rate matters, ninety percent CPU on a service that is responding normally does not.
Every alert carries a runbook explaining what it means, how to verify quickly whether it is real, and the first diagnostic steps. Alerts without runbooks eventually become alerts that get silenced. Thresholds are calibrated against observed behaviour, and the alert set is reviewed on a schedule: rules that have never fired, and rules that fire falsely on a regular basis, are either fixed or removed.
Logs and diagnosis
Metrics tell you a problem exists; logs tell you why. Centralised aggregation with Loki or Elasticsearch is the difference between finding a root cause in five minutes and connecting to twelve servers in sequence. We set tiered retention policies, because keeping everything hot for a year gets expensive quickly, and NIS2 logging expectations are satisfied by well-designed retention rather than by keeping the maximum of everything.
For distributed systems we add request tracing through OpenTelemetry, so a slow request can be followed across every service it touches. Without it, diagnosis in a multi-service architecture relies heavily on intuition and on whoever happens to remember how the call path works.
Service level objectives
We define SLOs with the business, starting from what users genuinely tolerate. Availability of 99.9 percent allows roughly forty-three minutes of downtime per month; 99.99 percent allows under five. The cost difference between those two targets is substantial, and the decision should be made deliberately rather than by writing an appealing number into a contract.
Once a target exists, the error budget becomes a practical decision tool. When it is spent, priority shifts from new features to stability. That conversation is considerably more productive than arguing about who caused the last incident.
Who this is for and what changes
The service suits organisations whose daily revenue depends on system availability, teams that have monitoring but do not trust it, and companies that must demonstrate incident detection capability for compliance purposes. As an EU-based provider we can also keep telemetry and log data within EU regions, which matters when logs inevitably contain personal data such as IP addresses and user identifiers.
The practical outcome is that your team learns about problems before your customers do, and average incident duration falls because diagnosis no longer starts from a blank page.