AccelerUp
One place to see what production is doing, be told when it stops doing it, and fix it without opening five other tools.
AccelerUp is the monitoring and incident-management platform this team runs production on. It watches services, servers, databases, the CDN, the data warehouse and the deploy pipeline; it decides when something is wrong; it pages the right person; and it keeps the record of what happened afterwards.
It is one application, not a suite. The reason an alert can say "errors rose
on /checkout eleven minutes after release 4.18.2 went to production, on the
three servers that got it first" is that the error groups, the release
changeset and the per-server rollout all live in the same database.
Start here
What it covers
| Area | What it answers | Where |
|---|---|---|
| Monitor | Is it up? How fast? Which server, which country, which pool? | Monitor |
| Logs and errors | What did it say about itself, and what was unusual? | Logs and errors |
| Alerting | Should somebody be told, and who? | How alerting works |
| Incidents | Who is handling it, what have they tried, what did we learn? | Incidents |
| Fleet | What is running on each box, and can I act on it from here? | Fleet |
| Delivery | What shipped, when, where, and did it make things worse? | Delivery |
| Data warehouse | Query the warehouse — and alert on what the query returns. | Data warehouse |
| Feature flags | Ship it dark, turn it on for 5%, measure, ramp or revert. | Feature flags |
| FinOps | What does the infrastructure cost, and what is it heading for? | Cloud spend |
| Copilot | Ask a question about production in English; let it read the data. | Copilot |
The three ideas worth knowing up front
Detect, surface, offer a fix
Nothing in AccelerUp fails silently if it can help it. When a rule cannot evaluate, a data source stops answering, or a panel falls back to a weaker source, the screen says so and says why — rather than looking exactly like a working one with nothing to report.
This is the single most common cause of "the monitoring did not tell us": not a missing feature, but a degraded one that looked healthy. Where a page can only show part of the answer, it tells you which part.
No reading is not evidence of recovery
An empty result, a closed run window, an unreachable host — none of these resolve an alert. A condition that fired at 18:00 is still open at 09:00 unless something actually measured it and found it well again. This is deliberate and it applies everywhere: SQL alerts, agent rules, service checks.
Code knows shapes, data knows vendors
There is no branch anywhere in the product that says "if this is <some vendor>". Collectors, health checks and coverage detection work from the shape of what they find — a Prometheus exposition, a health document, a listening port — so a new service is supported by adding data, not by adding code.
Conventions used in this documentation
A note adds context you will want but could work without.
A tip is a shortcut or a better way to do the thing you are already doing.
Important means you will get a worse outcome if you skip it.
A warning marks something that can cause a real problem — a missed page, a wrong number on a dashboard, an alert that never fires.
Caution marks something destructive or irreversible.
Pages that describe behaviour end with the source files that implement it. If this documentation and the code disagree, the code is right — and the page is a bug. See Contributing to these docs.
Getting help
- The search box (
⌘Kor/) covers every page here. - Troubleshooting collects the failures this team has actually hit, with the resolution.
- Glossary defines every term the product uses in a specific way.
Part of Getting started — What AccelerUp is, the words it uses, and the first hour with it.