Telemetry standards
Rules for log formats, metric names and trace context that every service follows.
Service offering
Observability standards
Any engineer able to follow a single request through every service it touches.
We agree how every service emits logs, metrics and traces, then build the platform that collects them: OpenTelemetry instrumentation, correlation IDs across services and alerts based on error budget burn. The standards come with libraries and templates, so teams adopt them without extra work.
Telemetry often contains personal data, so the standards define what may be logged, where it is stored and how long it is kept, in line with the UAE PDPL and the Saudi PDPL.
What the work involves
Instrumentation libraries
OpenTelemetry libraries and templates that add correlation IDs and traces by default.
Burn-rate alerting
Alerts that fire when an objective is at risk, not on every spike.
Measured reliability
Every improvement tied to an objective or an incident trend you can see on a dashboard.
Blameless learning
Reviews focus on how the system failed, so people keep reporting problems.
When observability needs standards
Standards are needed when each team instruments differently and incidents stall at service boundaries.
- Logs from different services cannot be joined for one request.
- Teams pay for several monitoring tools with overlapping data.
- Personal data appears in logs without anyone deciding it should.
Talk to us about observability standards
Tell us what you need to achieve and by when. We will propose a scope, a team and an itemised quotation.