Incidents
Incidents is the part of atrim.ai that tells you when something is wrong instead of waiting for you to go looking. A condition in your telemetry opens an incident, a notification goes out, and the incident closes itself when the condition clears. It is a complete loop, not a queue you have to poll.
It lives under its own top-level Incidents entry and is on by default.
How the loop behaves
Section titled “How the loop behaves”- Detect. atrim.ai evaluates your telemetry on a periodic cycle (about every five minutes). A condition has to persist across two consecutive cycles before an incident opens — a single bad cycle will not page you.
- Notify. When an incident opens, a message goes to your sign-up email and/or a webhook you have set up. A second message goes out when it resolves.
- Resolve. When the condition has been clear for two consecutive cycles, the incident resolves itself. An incident whose signal simply goes quiet is force-resolved after a few hours so nothing lingers as firing forever.
An incident moves through firing → acknowledged → resolved. You can acknowledge one to show it is being handled, and it still auto-resolves when the condition clears.
The list
Section titled “The list”The Incidents list shows each incident with its severity (critical / warning / info), its
state, its title and the services it affects, and when it last fired. Firing incidents
are tinted so they stand out, and a recurrence badge marks one that has fired more than once. Filter
by service, state or severity; acknowledge or resolve inline, singly or in bulk. When there is
nothing active you get an All Clear! panel rather than an empty table.
An incident in detail
Section titled “An incident in detail”Opening an incident shows:
- AI Analysis — a written summary of impact, probable cause and suggested next steps, already on the record when you open it. To size the impact, I walk the service graph your traffic draws and measure the blast radius — the downstream services that depend on what broke — then weigh it with the incident’s severity and whether it hit during business hours.
- Overview — the affected services, the evidence (links to the traces and the time window behind it), and metadata such as when it was first seen and how many times it has recurred.
- Timeline — the audit log: created, acknowledged, resolved, reopened.
- Deliveries — every notification attempt, its channel and target, and whether it was delivered.
From here you can Acknowledge, Resolve (with an optional note), Snooze it for a set period, jump to the underlying requests with Investigate, or run Analyze Root Cause over its trace.
Notifications
Section titled “Notifications”- Email goes to the address you signed up with — no setup, no counterparty to configure first.
- Webhooks are managed under Settings → Alerting. Create, edit and test-fire them in-product, and filter each one by severity so a webhook only receives what you want. A Discord webhook URL is recognised and formatted for Discord automatically.