FiretrailDocs
Open app

Introduction

Some pull requests are cheap to merge and expensive to live with. The code works, the tests pass, the reviewer approves — and three weeks later someone spends an afternoon debugging a problem that traces right back to that merge.

Firetrail exists to catch that before it happens. Every time a pull request opens, Firetrail reads the diff and answers one question: how much future debugging is this change likely to cost? It gives you a score, and — more importantly — it explains exactly why, in terms you can act on: "this PR mixes a refactor with a behavior change", "this touches deploy config", "none of this new code is tested".

Advice, not gates

Everything Firetrail tells you is advice. By default it never blocks a merge, never fails your CI, and never makes you wait. It posts its findings as a comment and a neutral check on the PR, and the full detail lives in the app. You stay in charge of what merges.

(If your team wants enforcement, that exists too — see Merge Checks — but it's opt-in, and it starts in a simulation mode that can't block anything until the check has proven itself.)

Honest about being AI

Firetrail's analysis is done by AI reading your diff. We think that's a feature — it works on any language and any project with zero setup — but it also means every number is an informed estimate, not a measurement. So we label estimates as estimates, we tell you when a PR was too large to analyze in full, and we show you the evidence behind every claim so you can judge it yourself. If Firetrail says a PR is risky, you should always be able to see why and decide whether you agree.

The four big ideas

Everything in the product builds on four pieces:

  • Future Debug Cost — the headline score, 0 to 100, for every PR. Higher means the change has more of the patterns that tend to come back and bite. The score always comes with an itemized breakdown of what added points.
  • The review team — a panel of AI reviewers, each with a different specialty (backend, frontend, security, database, accessibility, software design, SRE, QA, privacy and performance), who each read the PR and give an independent opinion with concrete findings. Your plan sets how many review each PR, and you pick which ones.
  • Patch coverage — an estimate of how much of the code your PR adds is exercised by the tests in that same PR. No CI integration needed.
  • Origin tracing — works backwards from a bugfix: which past PRs introduced the lines this fix is correcting, and how risky did they score at the time? This is how you find out whether the scores actually predict your bugs.

Where to go first

Setting up? The Quick start gets a repository connected and your first PR analyzed in a few minutes.

Trying to understand a score you just saw? Read Future Debug Cost — it explains the bands, the breakdown, and what to do at each level.

Curious what's checked? Classifiers walks through each built-in check in plain language.

Working in Claude Code, Cursor or Codex? The Firetrail MCP brings the analysis into your coding agent: ask it for a Review Brief of a PR, or on Business, to rework one.

Everything in the docs

Getting started — Quick start · Connecting GitHub

Concepts — Future Debug Cost · How analysis works

Working with pull requests — Pull requests list · The PR analysis view · Classifiers · Custom classifiers · The review team · PR Quiz · Patch coverage · Origin tracing · Merge Checks

Firetrail MCP — Firetrail MCP · Rework · Review Brief

Insights — Engineering Health · Business Impact · Classifier Analytics · Team Comparison · Historical Chat

Account — Plans & billing · Cost & usage