Replay an incident
Try it on an incident of your own
Take an incident your team has already been through and see how ForgeOps would have read it. Give it the errors from around that time, in whatever form you have them, and it replays them minute by minute through the same rules a live project gets: when it would have detected it, what it would have named as the likely cause at each point, and what the evidence said against it. Tell it what your team found, and it shows the two side by side. No account needed.
Getting the most out of it: our own incident file
An export of errors is enough to start, and the replay tells you what it couldn't check without the rest. To
give it everything (what each deploy changed, query and endpoint timings, traces), use our incident file. Only
errors is required in it. Download an example file
(it's the one behind our example replay), or see
the full format.
| Section | Each entry | What it's used for |
|---|---|---|
errors | occurred_at, exception_class, and optionally message, backtrace, release, user_id, count | Detecting the incident, counting who it hit, and matching stack traces to changed files |
deploys | deployed_at, release, and optionally changed_files, pull_request_number, deployed_by | Whether a deploy lines up, and whether what it changed is in the failing code |
performance | kind (controller, query, http, or job), name, period_ended_at, durations_ms | Slow queries, slow outside services, slow endpoints |
spans | trace_id, kind, name, started_at, duration_ms | Looking inside the slowest request for repeated queries |
failures | kind (job or dependency), name, occurred_at | Failed background jobs and failed calls to outside services |
metrics | name, recorded_at, value | Database connection-pool pressure |
Up to 2,000 errors and 6 hours of time.
Logs aren't read yet. Times are ISO 8601, like 2026-09-24T10:38:10Z.