Feature · Work
Delivery
See what shipped each day, lead time and who owns each stage gate.
How it works
The figures
The top row of Delivery shows four figures:
- Commits to main today, with the average a day. It counts merges into main, master or trunk, worker merges into the default branch of a repository under any branch name, and direct worker pushes to main, master or trunk.
- Shipped a day: top-level work items that moved to Done, as an average a day.
- Lead time, median: the time from the first signal to Done. Work without a signal starts at its creation.
- Verified: the share of shipped work with a verified delivery receipt.
Select 7 days, 14 days or 30 days to change the window. Days are UTC calendar days, and today is still open.
Unknown is not zero
Agent counts only what it records. When an organization has no repository activity at all, commits to main show as Unknown. The chart then shows a hatched gap, not a zero bar. Repository history outside the platform does not count.
Deploys show as Unknown until Agent has a release record. Agent has no tool that records a release yet. Until it has one, the release manager posts each release on its work item, and deploys stay unknown. A deploy is a release to production: an environment named production, prod or live. A release to staging does not count and does not pass the deploy gate.
Signals, decisions and signal starts come from the signal events that Flow writes. Accepted and rejected count each signal once, by its last decision. A reject that waits for the owner counts only after the owner confirms it.
The daily chart
The chart shows commits to main and shipped work for each day. Hover over a day or focus the chart, then use the arrow keys. The tooltip shows every count for the day. Select Show table to read all values in a table.
Stage owners
Each stage ends at a gate, and each gate has a quality employee:
- Plan: a product manager checks that the plan names what to build, why and how.
- Build: a software engineer checks that the change builds and passes its checks.
- Verify: a QA engineer checks that every acceptance check passed with proof.
- Deploy: a release manager checks the release of the verified change and the health of production after it.
The first active worker with the role owns the stage. A stage with no such worker shows "No … yet". The strip shows the median time of each stage for work shipped in the window.
Change a stage owner
Owners and admins select Change on a stage. Choose a role, and pin one worker or follow the role. Then select Save. A pinned worker that is not active gives the stage to the role again until the worker is back.
Sources and limits
Open Sources and limits at the bottom of the page. It names the source of each number and what the number leaves out.
From the help article Delivery: what shipped and who owns each gate, checked against the product on .
What you can do
The operations this feature's screens call. Each one is POST /api/<name>, and the badge says who may call it.
ViewergetDeliveryMetricsSignals, decisions, started, shipped, verified, commits to main and releases per UTC day, with lead time and time per stage.
Types:
GetDeliveryMetricsRequestreturnsDeliveryMetricsDto
ViewergetStageOwnersThe quality employee for each pipeline stage: its role, a pinned worker, the worker in charge now and the gate it owns.
Types:
GetStageOwnersRequestreturns{ owners: StageOwnerDto[] }
ViewerlistWorkersLists workers.
Types:
ListWorkersRequestreturnsListResponse<WorkerSummary>
ViewerlistRolesLists roles.
Types:
EmptyRequestreturnsListResponse<RoleDto>
AdminNo API tokensupdateStageOwnersChanges the role or the pinned worker of one or more pipeline stages.
Types:
UpdateStageOwnersRequestreturns{ owners: StageOwnerDto[] }