Triage verdict
Know in seconds whether it needs you right now
Every issue and incident opens with one verdict, Needs attention now, Investigate, Monitoring, or Resolved, and the facts behind it, one per line: who it's hurting, how fast it's moving, which endpoint, and what just shipped.
The first minute of triage, answered for you
The top of an issue answers the question you open it with: do I need to deal with this now? Needs attention now means an open incident rated high or critical behind it, a sharp climb reaching real customers, or so many customers affected that the rate barely matters. Investigate means worth a look but not yet a fire: a brand new issue, one that just came back, a real spike, or a low-severity incident. Monitoring is everything steady or ignored. The cutoffs are the same ones incident detection uses, so an issue and its incident never disagree.
Under the verdict, one fact per line: failures since it started, how many customers it's reaching and how many of them failed more than once, when it started, how the last hour compares with the one before, and the deploy that went out just before it, with its pull request and who shipped it. An issue that's part of an open incident links straight to it.
Below that, Where to look shows the likely cause and up to four numbered next steps, each with one line of why and one button: the deployment, the slowest captured request's trace, the slowest query in it, and the outside service it waited on.
The verdict, and every fact it rests on, one per line.
Which endpoint, and how hard it's failing
Errors from every server SDK (Ruby, Python, Node.js, PHP, Perl, Elixir, Java, .NET, and Go) say which request they happened in, so the verdict names the endpoint most occurrences came from and what share of them it accounts for. When the SDK reports request counts too, it adds how much of that endpoint's traffic this issue failed in the last hour, and only once there are enough requests for the number to mean something.
What shipped, without leaving the issue
With GitHub or GitLab connected, ForgeOps reads each deploy's changes since the one before it, once, with the access token you already gave it: how many commits and which files. The likely cause checks those files against the failing stack traces. The summary shows next to any issue or incident that started after that deploy, alongside a link to the full comparison. Every alert, on every channel, and every on-call page carry the same verdict, the deploy just before it, and the likely cause, so the first call can be made without opening anything.
See it on your own data
Free plan included, no credit card required. New organizations start with 14 days of Business.
Get started freeGet