Triage & Gates

Overview

Triage & Gates (route /triage) is the "things waiting on you" screen. It combines two kinds of decisions — approvals (an agent proposed a change and needs a yes/no) and incidents (an automated monitor found a problem) — and adds the tools to set up monitoring, review past incident write-ups, and configure where alerts get delivered.

Four tabs, each with a count badge when it has something in it:

Queue

Everything waiting on a human decision, most urgent first — critical incidents outrank approvals, which outrank warning-level incidents; ties break oldest-first. Each row shows a status chip (Approval Critical Warning), a summary line, and a relative timestamp (hover for the exact time); critical rows get a red left-edge stripe. Click a row to open its detail in a slide-over panel.

Empty state: a checkmark and "Nothing needs you right now. Approvals and incidents will appear here the moment they're raised."

Reviewing an approval

The panel shows the proposed change — as a Terraform-style plan viewer, an "Operation Review" summary, or plain text — plus which task raised it and when. Two buttons, Reject and Approve, each opening a confirm step before anything commits:

A secondary button, "Share as mobile link", mints a one-time, no-login approval link you can text or send to your phone — see Approvals & permission modes → mobile link for exactly what that page looks like.

Reviewing an incident

Shows the severity (CRITICAL / WARNING), the summary, the triggering signal, and when it was detected. Buttons depend on status: Acknowledge and Resolve if open, just Resolve once acknowledged, and no buttons (a green "Resolved" chip instead) once closed. Unlike approvals, these are single-click — no confirm step, since acknowledging or resolving is reversible bookkeeping rather than an action against your infrastructure.

Monitors

Recurring, plain-language health checks that watch your infrastructure — anything one of them finds shows up in the Queue as an incident.

1. Type what to watch in plain language, e.g. "monitor ec2 instances for 24h, report incidents", into the text box.
2. Click Start monitor (or press Enter). The button reads "Creating…" while it sets up.
3. The new monitor appears as a card with a Run now button, a cadence (cron schedule), a running check count, and last-checked time.

Each monitor's status chip is one of: Watching (active), Window ended (expired), or N incident(s) (something's currently open). A summary line at the top shows total monitors and total checks run. Empty state: "No monitors yet. Start one above — e.g. 'check the staging load balancer every 15m for 7d'."

Postmortems

Auto-drafted write-ups for every resolved incident.

If any exist, stat chips summarize resolved/open counts and mean/median time-to-resolve. Each postmortem is collapsed by default (title, action-item count, when it was generated, and a Read/Hide toggle); expanded, it shows Summary, Impact, Root cause, Remediation, and a list of action items. Empty state: "No postmortems yet. One is drafted automatically each time an incident is resolved."

Routing

Where incident alerts are delivered, and who gets paged if nobody acknowledges one in time. Unacknowledged incidents escalate through your on-call list in order.

Click Save routing (reads "Saving…" while in progress) to apply changes. You need at least one delivery channel configured for incidents to reach anyone — this is exactly what the warning banner at the top of the page is checking for.