How an incident runs

Nightjar takes over after the alert, end to end on GitLab.

1. Probe. A scheduled probe checks real customer journeys in production. When one fails, the pipeline rolls back first.
2. Incident. An incident issue is opened with the exact failing request, expected vs. actual response and the suspected code location. It is assigned to the GitLab Duo Developer Flow.
3. Fix. AGENTS.md makes the agent write a regression test first, then the smallest fix.
4. Proof. The new test must fail on the old code and pass on the new code, and no existing test may be changed.
5. Gate. A risk gate decides how much autonomy the change gets.
6. Release. No-traffic staging revision, smoke test, then exactly that revision is promoted. The pipeline writes a postmortem into the incident.

Proof: red before, green after

The risk gate

• Auto-merge when the score is at most 30 and nothing escalates.
• Escalate when the regression proof fails, a protected path is touched (for example app/tax_rates.py, owned by Finance in CODEOWNERS), or a new Critical/High finding appears. A human reviewer is requested.
• Block when an existing test was edited or a secret was found. The job fails.

The gate runs the tooling and policy of the target branch, so a merge request cannot loosen its own gate.

Postmortem written by the pipeline

Architecture

What this does not claim

• The gate is automation, not an access control. Branch protection and required approvals are project settings that this project's role cannot change; the gate requests a reviewer instead of enforcing one.
• Probes catch what they test. The release smoke test runs a small set of critical journeys, the scheduled probe runs the full set, including edge cases such as pasted coupon codes.
• Incident to agent hand-off uses a personal access token so the flow trigger fires; the merge request then appears under that account.
• The mapping from a failing endpoint to a suspected file in the incident is a fixed table, not a diagnosis.