What it is
A forensic tool for feature flag incidents. It reads change logs from LaunchDarkly, Unleash, Flagsmith, GrowthBook, your own audit table or plain notes.
Incident forensics for feature flags
Find the flag change that broke production.
Flag Autopsy lines up your flag change log against an error or latency graph, finds the moment the spike began and ranks every change by how likely it is to be the cause. You get a prime suspect, the time it took to kill it and a report for the postmortem.
CASE 0421checkout errors
- 1pricing_cache 25% to 50%
- 2checkout_v2 0% to 50%Prime suspect
- 3dark_mode on
Who it is for
On call engineers, release managers and SREs who need to know quickly which toggle to flip back, and teams writing the postmortem afterwards.
What it solves
When errors jump, five flags may have changed in the last hour. Instead of guessing, you see which change lines up with the spike and what the evidence is.
Run the autopsy
Paste the change log and, if you have it, the metric around the incident. Everything is analysed in this page and nothing is uploaded.
JSON lines, a JSON array or plain lines such as: 14:02 mira turned on checkout_v2 in prod 50%
Time and value per line, for example 14:03,2.9. Error rate, 5xx count or p95 latency all work. Optional.
Only needed without a metric. For example 14:03 or 2026-10-21 14:03.
The findings appear here
Paste a change log and press Run autopsy, or open the sample case to see a full report.
How it decides
The score is evidence, not proof. It tells you where to look first.
Spike detection
Each point is compared with the median of the points before it. A spike starts when a value is at least twice the normal level and well outside its usual noise.
Timing
Changes made minutes before the spike score highest. The score fades over the following hour and changes made long after the start are ignored.
Before and after
For every change it compares the metric in the 15 minutes before and after. A sharp rise adds to the score.
Exposure
Turning a flag on or raising its rollout adds suspicion, more for big jumps. Turning something off or a change outside production lowers it.
Confirmation
If turning the flag back off was followed by recovery within 20 minutes, that is the strongest evidence of all.
Hygiene
Separately it flags habits that make incidents more likely: skipping staging, huge jumps, flapping, changes at night and changes without an author.
How to use it
Export the change log
Copy the audit log of your flag tool for the incident window, or write the changes down by hand with their times.
Add the metric
Export the error rate or latency from your dashboard as time and value. If you have no metric, type the incident start instead.
Read the verdict
Check the prime suspect, its evidence and the chart. Markers show exactly when each change happened.
Share the report
Copy the report into the incident channel or download it as Markdown for the postmortem.
Good to know
- Times without a zone are read as written. Times with a zone are converted to UTC, so keep both inputs in the same zone.
- Plain text lines are understood best in English. JSON fields work in any language.
- Correlation is not cause. A deploy or a traffic surge at the same moment will not appear here.
- Nothing leaves your browser. Remove secrets or personal data before sharing the report.
Questions
Which flag tools does it work with?
Any tool whose audit log you can copy. Common field names such as key, flag, environment, user, from, to and rollout are recognised automatically.
What if I have no metric?
Type the incident start time. The changes are then ranked by timing, exposure and environment only.
Why is my staging change scored zero?
A staging change cannot break production directly, so it is ruled out. It still counts as the staging step for later production changes.
Is the suspicion score a probability?
No. It is a weighted sum of the evidence capped at 95, because a tool like this can never be certain.