Observability
Prometheus, Grafana, logs, and traces. Alerts that on-call will act on, and an SLO that decides which of those alerts exist.
Who this is for
- On-call rotations that ignore their own alerts
- Teams adding an SLO for the first time
- A dashboard nobody opens during an incident
Alerts someone will answer
Dashboards and alert routes on-call will open, plus a runbook for the alert and a named owner. We suggest removing alerts that have never led to an action.
One SLO before a wall of them
One availability or latency target for a path a user actually takes. The error budget tells the team when a problem is worth acting on. More SLOs come after that one is trusted.
The tools you already run
Prometheus and Grafana on the cluster, or the cloud tools you already pay for. A new vendor is a decision, not the starting point.
Capabilities
- Prometheus, Grafana, and Alertmanager
- Logs (ELK or the cloud logging you already have)
- Traces for one user-facing path
- SLOs and the alerts that follow from them
- A runbook for each alert that pages someone
Common questions
Do you replace the monitoring tool we already pay for?
Not by default. We work in Prometheus, Grafana, and the cloud tools you already have.
What is a useful first SLO?
One user-facing path: availability or latency for a single service, with an error budget the team can see.