Deploy-correlated observability
Know what your release actually did. Before the retro.
Plumbline puts every deploy on the same axis as the latency, errors and spend that followed it. When something moves, you already know which commit range to look at — and how sure we are.
13:0514:02 — deploy 4.19.214:05
What it does
Four things, done properly, instead of forty dashboards.
Most tools show you that a number moved. The expensive part of an incident is deciding what moved it. Plumbline is built around that second question.
- Deploy timeline
- Every release, feature flag flip and config change on one axis with your latency, error rate and spend. The question is always 'what changed?' — so the change log is the primary axis, not a sidebar.
- Blame that holds up
- Plumbline attributes a regression to a specific commit range and tells you the confidence. When it cannot separate two candidates, it says so instead of guessing.
- Budgets, not alerts
- Set a p95 and an error budget per service. Plumbline pages someone only when the budget is on track to be spent, which is a different and much rarer event than a threshold being crossed.
- Rollback in one hop
- From a flagged release, revert the deployment or the flag without leaving the timeline. The action and its outcome are written back to the same record.
Release ledger
Today, on one service.
| Release | Shipped | Author | p95 ms | Err % | State |
|---|---|---|---|---|---|
| 4.19.2 | 14:02 | release-bot | 372 | 1.84 | Rollback held |
| 4.19.1 | 11:47 | d.okafor | 128 | 0.06 | Live |
| 4.19.0 | 09:15 | release-bot | 124 | 0.05 | Live |
| 4.18.7 | Yesterday | m.haas | 131 | 0.07 | Live |
| 4.18.6 | Yesterday | release-bot | 126 | 0.05 | Live |
Plumbline held 4.19.2 automatically: the error budget for api-gateway was on track to be spent in 40 minutes. Nobody was paged.
“We stopped arguing about whether it was the deploy. That argument used to be the first forty minutes of every incident.”
Free while you evaluate