This report needs results. Take the Paradise Index, then choose "PDF report".
o11yparadise · Paradise Index report
/100
Score by area
| Area | Focus | Score |
|---|---|---|
| Detect | Know users are hurting before they tell you | |
| Debug | Get from symptom to cause quickly | |
| Ship | Change production safely | |
| Respond | Handle incidents calmly | |
| Sustain | Keep it humane and affordable |
Fastest wins
All answers
Detect
- Pages are tied to SLOs and error-budget burn, not CPU spikes
- We measure what users feel on key journeys: synthetic checks or real user monitoring
- Dashboards show data freshness, and we alert when telemetry goes quiet
Debug
- Every service dashboard leads with the four golden signals
- Logs carry trace IDs, so we can jump from a metric to a trace to its logs
- We tail-sample traces, so slow and failed requests are always kept
Ship
- Deploys go out as canaries that roll back on their own
- Deploys and config changes show up as markers on our graphs
- Alerts and dashboards live in git and get code review
Respond
- Every alert that can page links to a short, tested runbook
- We alert on container restarts and memory pressure before users notice
- Incidents have a named lead, a comms channel, and regular status updates
Sustain
- Postmortems ask how the system allowed it, not who did it
- We track pages per shift and fix or delete noisy alerts every week
- Someone owns telemetry cost: cardinality is guarded and retention set per signal
- We instrument with OpenTelemetry, so switching backends never means re-instrumenting