SnapFlow
Incidents
Every alert ends in a safe, verified fix: a free read-only diagnosis, a proposed fix you approve in Slack or the app — or, where you allow it, a fix SnapFlow makes on its own.
Overview
SnapFlow takes the alerts your monitoring already sends — and problems people report in plain words — and turns each real problem into one incident. Every incident gets a free, read-only diagnosis. SnapFlow then proposes a fix and either asks you (in Slack and in the app) or, where you allow it, fixes it on its own. Every fix runs with all of SnapFlow’s protections: each change is recorded and can be undone, production limits apply, and health is checked afterwards. You are charged only for a fix that is verified.
Open it from Advanced → Incidents. SnapFlow does not replace your monitoring or on-call tools; it handles the step they hand to a person — fixing production safely.
How an incident moves
- An alert arrives (CloudWatch, Sentry, Grafana, PagerDuty, Datadog, New Relic, any JSON), a SnapFlow monitor finds a problem, or someone writes "checkout is slow". Alerts about one problem join one incident — ten alerts for one outage start one diagnosis, not ten. A sudden flood becomes one "alert storm" incident.
- SnapFlow diagnoses it, read-only. Nothing is changed and it costs nothing. It reports what is wrong, the evidence, the likely cause, and a proposed fix.
- Did SnapFlow cause it? SnapFlow records every change it makes. If one of its jobs changed an affected resource in the last 24 hours and the diagnosis confirms that change as the cause, the fix it proposes is to roll that job back.
- The fix is planned and priced as a normal job, with a fixed price charged only if the fix is verified.
- It runs on its own, or it asks. See Automatic fixes. When it asks, the card says exactly why.
- Verified, then closed. The incident resolves, PagerDuty is resolved with the outcome, and a post-incident review is drafted. If health gets worse after a fix, the fix is rolled back and a person is asked.
What the statuses mean
| Status | Meaning |
|---|---|
| Open | A problem nobody has picked up yet. |
| Diagnosing | The read-only diagnosis is running. |
| Needs approval | A fix is ready and waits for an owner to approve it. |
| Fixing | The fix is running. |
| Needs a person | The fix failed, was rolled back, or is waiting on something only a person can do. |
| Fixed | Fixed by SnapFlow and verified. |
| Resolved | The alerts cleared, or a person resolved it. |
One incident
Click an incident to see everything about it: what SnapFlow found (with its evidence and confidence), the proposed fix with Approve / Decline, the timeline of everything that happened, the alerts behind it, and — once it is over — the post-incident review, which you can edit and save.
If the diagnosis finds nothing wrong, nothing is "fixed": a problem a person reported closes as No problem found; an alert is marked No fault found and resolves when the alert clears.
Anyone who may run jobs can Acknowledge it, add notes, or ask SnapFlow to Diagnose again. Approving or declining a fix, and marking an incident resolved, takes a workspace owner.
If the alerts clear, or someone resolves the incident, while a fix still waits for approval, the fix is withdrawn: nothing runs and anything reserved for it is returned.
Reporting a problem
Type what is wrong in Report a problem at the top of Incidents — for example "orders API returning 500s since 10:00". It opens an incident with the same free diagnosis an alert gets. You can do the same in Slack (below).
Connecting your alerts
Advanced → Incidents → Connect lists one private URL per tool. Each URL belongs to your workspace only — keep it private.
| Tool | How |
|---|---|
| AWS CloudWatch | Create an SNS topic in your connected AWS account and add an HTTPS subscription with the CloudWatch URL; SnapFlow confirms it itself. Send your alarms (and their OK) to the topic. Topics from other AWS accounts are refused. |
| Sentry | A Custom Integration webhook or an alert rule’s webhook action. Issue, event and metric alerts work. |
| Grafana | Alerting → Contact points → Webhook. Resolved alerts close the incident. |
| PagerDuty | A Generic Webhook (v3) on a service. Add a REST API key (below) so SnapFlow can acknowledge, note and resolve. |
| Datadog | Integrations → Webhooks, then mention the webhook in your monitors. |
| New Relic | A webhook destination used by a workflow; the default payload works. |
| Anything else | POST JSON with title, status (firing/resolved), severity, service and resource. |
SnapFlow monitors (Advanced → Monitors & routing) raise incidents here too; when a later check is healthy again, the incident resolves.
Slack
Click Add to Slack under Connect and pick an incident channel. Then:
| Each incident is a thread | The diagnosis, the proposed fix with Approve / Decline buttons, progress, and the verified result all appear in one thread. |
| Report in plain words | Write a problem in the incident channel ("checkout is slow"), mention @SnapFlow anywhere, or type /snapflow checkout is slow. Your message becomes the incident’s thread. |
| Ask a question | Mention @SnapFlow (or type /snapflow) with a question — "show me all EC2 instances in us-east-1". It runs read-only and answers in the thread: the answer, key facts and a table when it is a list. |
| Ask for a change | /snapflow add a staging S3 bucket is planned and priced, and the plan comes to the thread with Approve / Decline before anything changes. Start with incident: or job: to say which you mean. |
| Follow-ups in a thread | A thread is one conversation. Reply in it — "restart it", "what about its CPU?" — and SnapFlow runs the next turn: a new job (with its own price where one applies) that sees the whole conversation, answers in the same thread and is grouped with it in SnapFlow. In an incident's thread, mention @SnapFlow to ask or act; other replies are kept as notes. Ask about something else (another resource or service) and SnapFlow starts a new thread for it and links the two. |
| How it reads | The incident's first message is a card that updates as it moves, coloured by state: red needs attention, amber waits for you, blue is working, green is fixed, grey means nothing was wrong. The thread holds the diagnosis, any approval card and the outcome — each said once. |
| Who may approve | Only someone whose Slack email belongs to an owner of this SnapFlow workspace. Anyone else is told why. A card that changed since it was posted (a new price, a new step) cannot be approved from the old message, and a double click acts once. |
| One Slack, one workspace | A Slack workspace connects to exactly one SnapFlow workspace. Disconnect it there first to move it. |
Who can do what from Slack
SnapFlow recognises a person by the email on their Slack account and looks for a user with that email in the SnapFlow workspace this Slack is connected to. A SnapFlow account in another workspace counts for nothing here: everything asked in this Slack runs in the connected workspace, against its cloud accounts.
| What | Who |
|---|---|
| Ask a question | A member: runs read-only straight away. Anyone else: waits for a workspace owner to approve the plan and price. |
| Ask for a change | Everyone: planned and priced, then waits for an owner to approve. Nothing changes before that. |
| Approve or decline | Only an owner of the connected workspace. When someone who is not a member asks, the thread shows the plan without Approve / Decline, and each owner gets the card in a direct message from SnapFlow; the thread then says what was decided. Anyone else who presses a button is told why it was refused. |
| Report a problem | Anyone in the channel: it opens an incident with a free, read-only diagnosis. Someone who is not a member can report up to 3 an hour. |
Every job started from Slack shows who asked, under the request: "Asked in Slack by Mikela Perera · not a member of this workspace, so an owner approves before anything runs". The audit trail records the same person.
Nothing waits on Slack: the incident carries on, and everything is in the app.
PagerDuty
Add a PagerDuty REST API key and the PagerDuty user email SnapFlow should act as (Connect → PagerDuty; stored encrypted). For incidents that came from PagerDuty, SnapFlow then acknowledges them when it starts diagnosing, adds its finding as a note, and resolves them with the verified fix — or adds a note saying why the fix did not work. Incidents SnapFlow itself sends to PagerDuty (routing key under Monitors & routing) are acknowledged and resolved the same way.
Automatic fixes
Off until a workspace owner turns it on (Advanced → Incidents → Automatic fixes). Diagnosis always runs on its own. A fix runs without asking only when every one of these holds:
- Automatic fixing is on for the incident’s severity — and for production, only if you also allowed production.
- It is a known fix: the same problem was fixed and verified in your workspace before, it runs a verified SnapFlow capability, or it is rolling back SnapFlow’s own change.
- It is reversible: it removes nothing (no delete, no replace), changes no access (IAM), and every change is recorded for undo.
- It fits the environment’s change window and change limit.
- Its fixed price is within your per-fix limit.
- It is not a repeat: an automatic fix for this incident has not already failed or been rolled back.
Anything else asks, and the card names the condition that was not met. Every automatic fix runs under the health guard: if health gets worse afterwards, SnapFlow rolls it back on its own and tells you. Anything a fix tries beyond what its plan said (a removal, an access change, a step that cannot be undone) still stops for a person.
The numbers
The strip at the top of Incidents shows the last 30 days for your workspace: incidents seen, fixed and verified (on its own and with approval), the median time to fix, fixes the health guard rolled back, and fixes that made things worse. They are counted from the incidents themselves.
Pricing
Diagnosis is free. A fix is charged at its quoted price only when it is verified; a fix that fails, is declined, or is rolled back costs nothing. Nothing is charged per alert, per incident or per seat.