When your website or SaaS service goes from hobby project to business-critical infrastructure, the rules of the game change. An error is no longer an annoyance – it's lost revenue, damaged trust and, for more and more businesses, a reporting obligation. The good news: the tools to drive stable production have never been more mature than in 2026. The bad: many teams are collecting lots of data without being able to answer the one question that counts when the alarm goes off –why is it broken and how do i fix it now?
This guide walks you through the five building blocks—logs, metrics, tracing, alerting, and uptime monitoring—and how they fit together into an operation you can actually trust.
Observability vs. monitoring – why the difference matters
Classicmonitoringanswers questions you already know you want to ask: Is the CPU high? Is the API responding?Observabilityis about something more difficult – being able to ask questions you didn't anticipate, based on the data the system already sends out. When a customer reports that checkout hangs sporadically on mobile in a certain region, you should be able to drill down to those exact requests without deploying new code.
The foundation rests on three signals –logs, metrics and traces- which together provide both the overview and the details. Separately, they are blunt. Together, and correlated, they are your troubleshooting superpower.
The three signals in practice
Metrics – the pulse of the system
Metrics are numerical time series: requests per second, error rate, response times (percentiles, not averages – p95 and p99 reveal what the average hides), queue lengths, memory usage. They are cheap to store and perfect for dashboards and trends. The dominant open source stack is stillPrometheusfor collection andGrafanafor visualization, regardless of whether you operate yourself or buy a hosted variant.
Logs – the story of what happened
Logs are time-stamped events. The secret of 2026 isstructured logging: write logs as JSON with consistent fields (request-id, user-id, route, latency) instead of free text. Then they become searchable and filterable instead of a wall of prose. Add a commontrace idin each log row you can jump directly from a metric spike to the exact logs behind it.
Tracing – the path through the system
In an architecture with multiple services, queues and third-party calls, logs from a single service are not enough.Distributed tracingfollows a single request all the way through the system and shows where the time goes - was it 800ms in the database or waiting for an external payment API? That's the difference between guessing and knowing.
OpenTelemetry – the standard you should build on
OpenTelemetry (OTel)is today the self-evident, vendor-neutral standard for instrumenting applications. The point is that you instrument your codeonceand then can send the telemetry to any backend – if you change supplier, you don't have to rewrite the instrumentation. It's your best protection against lock-in.
Maturity varies between signals and languages.Tracingis stable across basically all languages, and the stable onesthe semantic conventions of HTTP(since v1.23.0) makes the telemetry look the same regardless of framework.Metricsis stable in most SDKs, whilethe log managementis the longest in Java, .NET, C++ and PHP but still under work in, among other things, Python and JavaScript as of spring 2026.OpenTelemetry Collector– the component that receives, processes and forwards all telemetry – has reached its v1.0 milestone and is the cornerstone of a modern pipeline. Always check the OTel official status page for your specific language before designing.
Alerting that wakes you up for the right reason
The most common mistake in operations is not too few alarms - it's too many. When every other notification is noise, the team stops reacting, and then you miss the alarm that actually means something. The solution is to sound the alarmsymptoms experienced by the user, not on every technical deviation.
SLO, error budget and burn rate
The Google SRE school provides a concrete framework. Define oneSLI(a measurable indicator, such as the percentage of successful requests), put oneSLO(the target, eg 99.9%) and you automatically get oneerror budget- how much you can fail before you break the target.Burn ratedescribes how quickly you burn through the budget: a burn rate of 1 means that you use up exactly the entire budget during the period.
Best practice ismulti-window, multi-burn-rate alarms: combine a short and a long window so that the alarm is both current and confirmed true. The Google SRE workbook suggests as a starting point thatpay directlywhen the burn rate exceeds 14.4 over an hour (2% of the monthly budget burned in one hour) and create amatterat burn rate over 6 over six hours (5% burnt). The result: someone is only woken up when there is a real, ongoing threat to the budget.
Page– urgent, requires human action now. Should be rare.
Ticket– needs to be fixed, but not in the middle of the night.
Info- good to know, ends up in a channel, doesn't wake anyone up.
Uptime monitoring and MTTR
Internal telemetry tells you what's going onInsidethe system. You also need to look from the outside.Synthetic monitoring– external robots that periodically make real calls to your site and your critical flows (can the user log in? Can an order be placed?) – catch errors that internal data misses: DNS, certificates, CDN, regional unavailability.
Don't just measureuptimein percentage. Two numbers guide the business:MTTD(time to discovery) andMTTR(time to restored operation). The whole point of observability is to push both down. Complete with an audience or internalstatus page- proactive communication in the event of a disruption saves enormously with support cases and trust.
Practical checklist for growing businesses
Instrument with OpenTelemetry from the start– cheapest to build right away, most expensive to retrofit.
Structured logging with trace-idin each row, so the signals can be correlated.
Define 1-3 SLOsfor your most business-critical flows – not ten.
Alert on symptomswith burn-rate-based thresholds; clean out noisy alarms aggressively.
Synthetic monitoringof login and purchase/conversion, not just of the home page.
Write runbooks- when the alarm goes off, the person who is woken must know the first steps without thinking.
Practice incidentsand hold blameless postmortems. The lesson, not the scapegoat.
Operation is also a matter of regulation in 2026
For many Swedish companies, stable operations and incident management are now a legal requirement. ByThe Cyber Security Act (SFS 2025:1506), which implements NIS2 and applies from 15 January 2026, covered businesses must be able to detect and report significant incidents within tight timeframes: an early warning within24 hours, an incident report within72 hoursand a final report within one month. Without good observability and practiced processes, those deadlines are difficult to meet. Monitoring is thus no longer just technology – it is compliance.
Get started right
Observability doesn't have to be overwhelming. Start narrow: instrument a critical flow with OpenTelemetry, set a single meaningful SLO and a burn-rate alarm, and add synthetic control of your most important user flow. Build from there. The important thing is not to collect the most data – it is to be able to respond quickly when there is a fire.
At ZORC, we build web and SaaS productions with observability, alarms and operation built in from day one, and help growing companies meet both uptime goals and NIS2 requirements. Do you want a stable foundation to grow on? Count on your setup ithe quote calculatoror get in touch viacontactthen we'll look at your operation together.
