Service 04
We define what good looks like for your services, instrument them properly, and build alerting that wakes someone only when a person is genuinely needed.
Overview
Two failure modes are equally common. Either there is almost no monitoring and outages are reported by customers, or there is a great deal of monitoring, hundreds of alerts a week, and the on-call engineer has learned to ignore all of it.
The fix in both cases starts with agreeing what your services are supposed to do, in numbers. Once that exists, dashboards have a purpose and alerts have a threshold worth defending.
What we provide
If something you need is missing from this list, it is a conversation during the proposal rather than a change request halfway through the build.
Availability and latency targets agreed with your business, not invented by engineers, and an error budget that makes the trade-off between speed and stability explicit.
Consistent instrumentation across services so a single request can be followed from the edge to the database and back without guesswork.
Alerts tied to customer-visible symptoms rather than individual resource thresholds, each one linked to a runbook and a clear owner.
One view for the on-call engineer, one for the engineering team, one for the business. Each answers a different question rather than showing the same graphs at different sizes.
Severity definitions, an escalation path, a communication template and a blameless review format your team can run without us.
Sampling, retention tiers and log volume management, because an observability bill that rivals your compute bill does not survive the next budget review.
Typical engagement timeline
Observability work runs five to nine weeks. The first two are mostly conversation rather than code, because instrumenting a service before agreeing what it should do produces expensive noise.
Weeks 1 to 2
Workshops with engineering and the business to agree what availability and latency actually need to be, per service, and what an acceptable bad month looks like.
Weeks 2 to 5
Metrics, structured logging and distributed tracing added consistently across services, using OpenTelemetry so the data is portable if you change vendors later.
Weeks 4 to 7
Symptom-based alerting with runbook links, plus the dashboards each audience needs. Existing noisy alerts are reviewed and retired rather than left running alongside.
Weeks 7 to 9
A rehearsed incident, a written review of how it went, and the escalation and communication templates your team keeps afterwards.
Key benefits
These are the outcomes clients tell us mattered most six months after the engagement ended, rather than the ones that sound best in a proposal.
Traces that cross service boundaries turn most investigations from an afternoon of guessing into a few minutes of reading.
When every page corresponds to something a customer would notice, on-call engineers start trusting their phone again.
Service level objectives end the argument about whether performance is acceptable by making it a number both sides agreed to.
Retention and sampling decided deliberately rather than discovered when the monitoring invoice arrives.
Questions we are asked
If your question is not here, ask it on the introductory call. We would rather answer it before a proposal than after one.
Usually not. Datadog, Grafana Cloud, New Relic, Honeycomb and self-hosted Prometheus all do the job well when configured deliberately. We instrument with OpenTelemetry so your data is not locked to one vendor, which means switching later stays a commercial decision rather than a rebuild.
Far fewer, and every one should be actionable. Teams we work with typically end up with somewhere between five and fifteen alerts that can page a human, each tied to a customer-visible symptom with a runbook attached. Everything else becomes a dashboard or a ticket.
During an engagement, yes, and we join incident calls as part of the work. Outside an engagement we do not offer a paid on-call service, because the honest answer is that a retained vendor is a slower path to resolution than a team that knows its own system. Enabling your team to handle it is the point of the work.
Fixed-scope engagements from EUR 14,000. 5 to 9 weeks.
Send us the shape of the problem and we will come back with a written scope, a timeline with dates, and a fixed price. The introductory call is free.