Incident Triage
Turns a night of alerts into a short list of grouped incidents, each with somewhere to look first.
Nine alerts at two in the morning are rarely nine problems. They are usually one problem seen from nine angles, and the first twenty minutes of an incident go on working that out. The concept groups the alerts, lines them up against what was deployed and what the service has done before, and drafts the impact summary somebody would otherwise be typing while still half awake. It would not wake anybody. That is the step it stops at. None of it is built yet.
Availability
In Development. Specified, and not built. The run below is the shape the job would take, not a recording of one. Nothing of it runs today, so it cannot be subscribed to and carries no price.
Intended user
Whoever is on call at two in the morning, and whoever has to write the summary afterwards.
Monthly price
Not purchasable. No price, and no subscribe button until it runs.
Nothing here runs yet, so there is no Subscribe and no Run on this page. Asking for it is what decides which of the five gets built first, and a close variation of it can be quoted as a custom build today.
What this is not.
The corrections worth making before anything else on this page is read, because each one is a thing a reader could reasonably assume and would be wrong about.
- No live outage map and no live status of anybody's service. Nothing on this page reads a real system, and no customer's logs appear here or would appear in anything public.
- Reading alerts and drafting a summary are read-only work and would need no approval. Paging an owner, or opening an incident of record, is the step it stops at — the rule is permission before a consequence, not a button on every calculation.
- What the feed did not record stays unknown and is printed as unknown. It would not be inferred, averaged or quietly filled in.
How the job would go.
Four steps, in order, ending where it stops. No timing is published for any of them: nothing has run, so there is nothing to measure, and a written duration shown as a measurement would be an invention.
Incident Triage, start to finish
Illustrative- Reads the alerts in the window
- Groups the ones describing the same failure
- Lines each group up against recent deploys
- Drafts the impact summary
Illustrative. The steps are written for this page to show the shape of the job, and none of it is a recording.
What would land when it finishes.
Grouped incidents, each naming the service involved, carrying a drafted impact summary and saying what is still unknown.
| Incident | Alerts | Where to look first | Not known |
|---|---|---|---|
| Checkout latency | 6 | Began shortly after the 02:14 checkout deploy | Whether anyone failed to pay or only waited |
| Payment retries | 3 | Downstream of the same service, same window | How many attempts, which the feed did not carry |
Nobody would have been paged. Paging is the next step and it waits. The services, the times and the alert counts are written for this page.
Illustrative. These rows are written for this page and are never a customer’s data.
Supported inputs
Kinds of source, from accounts you would connect in your own Tools workspace. Which account, and the credential behind it, are yours and never appear anywhere on this site. No named integration is listed, because none has been built.
- Alert feed
- Deploy log
- Status history
Output
Grouped incidents, each naming the service involved, carrying a drafted impact summary and saying what is still unknown.
IllustrativeApproval boundary
Page the owner on call?
Reading, checking and comparing change nothing outside your workspace and would happen on their own. Anything that cannot be taken back waits for you, and what it is asking about is shown in full rather than summarised.
Incident Triage is in development.
It is specified and not built. Billing does not exist yet and the usage allowance has not been measured, so there is nothing to subscribe to and no price to show. Asking for it is what decides what gets built next; a close variation of it can be quoted as a custom build today, against acceptance cases you write.
The rest of the catalogue.
- Invoice MatchingFinanceChecks every invoice against the order it came from and the goods that actually arrived.
- Month-End CloseFinanceClears the accounts that reconcile at month end and writes the first draft of the close narrative.
- Review Before MergeEngineeringReads a change the way a careful colleague would, before anybody is asked to approve it.
- Idle Cloud SpendEngineeringFlags cloud resources with no recorded activity, works out who owns each one, and estimates what stopping it would save.