Investigation

Every incident opens as a numbered path to where to look

An incident's page asks the questions in the order you would: who's affected, what changed, what likely caused it, and which request, query, and dependency to check, ending with a full timeline of what actually happened.

Up to seven steps, each with one next click

The page reads top to bottom as numbered steps. Needs attention now says how many customers are affected, how many failed once and how many repeatedly, how much the error rate changed, and how the affected endpoint's response time compares with before. What changed lists the deploys, feature flags, config, and dependency upgrades from the hours before it started, labeled potentially relevant. The likely cause follows, with its match confidence, its evidence, the pull request when a deploy is the match, and a recommended action.

Then the affected endpoint and its slowest captured request, the slowest database query in that request, and the outside service it was waiting on, each with one button to open it. A step with no data behind it is left out and the rest renumber, so there's never an empty stop. An issue opens the same way: what needs attention now, then Where to look, with the likely cause and a short numbered list of next steps.

An incident's page laid out as numbered steps: Needs attention now with 12 customers affected and the error rate up 300 percent, What changed with a feature flag, a config change, a stripe upgrade, and a deploy, and the likely cause at 90 percent match confidence

The top of the path: who it's hitting, what changed just before it, and the likely cause.


A timeline built from what actually happened

The last step is the full timeline: the deploys and recorded changes before it, when the endpoint slowed down, the first occurrence of the error, when the error rate rose and ForgeOps opened the incident, the first customer impact and when customers affected reached its count, each alert and on-call page actually sent, a human acknowledging it, and resolution. Every entry links to where its detail lives, and every entry is a real signal, row, or timestamp; nothing is estimated or fabricated to fill a gap.

The incident page and the postmortem document read from this exact same timeline, so the two can never silently disagree about what happened.

An incident's full timeline, from the deploy through the first occurrence, the error rate rising, and customers affected reaching 4, to the error rate returning to normal

Every entry is a real signal or timestamp, linked to its detail.


See it on your own data

Free plan included, no credit card required. New organizations start with 14 days of Business.

Get started free