Triggers and routing
The trigger decides when a run begins. Outcome routes decide what the graph does when a step passes, flags a problem, is rejected, or errors.
Triggers
Manual
Press Run from the saved workflow. Use it for ad hoc work and testing a new definition.
Label
Start a seeded run for an open backlog ticket carrying the configured label. The ticket becomes an entry input and the occurrence is claimed to avoid duplicate runs.
Schedule
Start from a cron expression. Fleet claims each occurrence exactly once and applies the same in-flight run cap as other triggers.
KPI
Check a bound KPI on a daily, weekly, monthly, or custom cadence. When the KPI needs attention, Fleet starts the intervention workflow with the KPI context attached.
Pull request
Start every enabled matching workflow when GitHub reports a configured PR action. Filter by base branch and draft state. Saving or enabling waits for the next event; it does not start a run.
One repository belongs to the workflow. It supplies the ticket system, working tree, and run scope.
Outcome vocabulary
| error | Available on every step. Unrouted errors fail the run. |
| pass / flag | Review outcomes. Pass continues; flag can route back for repair. |
| approved / rejected | Approval outcomes. Rejection can route back or end the run. |
Bounded fix loops
Develop → Review
↑ │
└─ flag ─┘ retry up to 2 times
│
└─ exhausted → NotifyRetry limits belong to the routed edge. When the limit is exhausted, the workflow can invoke another step, usually a notification or summary, before recording the failure. Review rounds receive their own previous flags so the loop converges on unresolved concerns.
Workflow-level failure handling
An optional failure handler catches an unrouted error or exhausted recovery path. Use it to prepare a failure summary or notify the operator. The handler does not convert the original run into success; it preserves the failure and the evidence around it.