Delivery metrics - Clocktopus Docs

Hours tell you what a period cost. Delivery metrics tell you how the work moved — what is stuck, what is slow to review, and which pieces were genuinely hard.

They sit on the dashboard and are built from what you already send: commits, pull requests, and the time already tracked against them.

Who sees them depends on whose work they describe. The dashboard has two tabs, and the board follows whichever one you are on.

On My work it covers the pull requests you opened, across every project you can reach, in every organisation you belong to. Everyone gets this, because reading how your own work moved is not a management act.

On Team it covers everybody's, across the projects of the organisations you own or administer. Only owners and admins have that tab at all: a board that lets every member rank every other member is a different thing entirely. It never reaches an organisation you only belong to, so work there never lands in a team figure of yours.

The team board lists everyone who can reach the projects in scope, including people with nothing recorded for the period — their row simply reads zero. An absent row and a quiet one are indistinguishable, so leaving people out would make it impossible to tell "everyone shipped" from "half the team is missing from this list". Expect non-engineers in the list for the same reason; they sort to the bottom.

Who counts as workforce follows the project's own access rules, so the list shrinks with the project filter: narrow the board to a restricted project and you get its owners, admins and granted members rather than the whole organisation. Anyone whose pull request the period covers stays on the list whatever their access is today — otherwise a revoked grant would leave a merged pull request in the chart with no row accounting for it.

[!NOTE] These are not a ranking, and they are not built to be one. Read the How to read these section before showing them to anyone whose work they describe.

What you need for them to work

Three things, and the widgets stay quiet until all three are true:

Your webhook sends pull request events. Push events alone are enough for time tracking, but a pull request opening pushes nothing at all — without the events there is simply no record that it happened.

There are two subscriptions, and they are separate checkboxes on both providers. Pull requests gives you states, cycle time, merge rate and complexity. Pull request reviews is what makes the review rate, time to first review and review cycles possible — nothing else produces them, and it is the one people most often miss. See Connect a repository.
The repository is linked to a project. Same rule as commits: unattached repositories have nowhere to file anything.
Time is tracked against the work. Effort is the backbone of the complexity metric, and it is the one thing a git host cannot know.

Data accumulates from the moment you subscribe, not before. A pull request merged last month sends nothing today, so the first weeks look sparse. That is expected, and not something to debug.

Which pull requests a period covers

A period covers the pull requests that finished inside it — merged or closed — plus the ones opened inside it that have not finished yet.

The close is what anchors it, so Merged means what merged in this period. It is the same set the merge bars beside your tracked hours draw, so the headline and the chart always agree. A pull request open for three weeks belongs to the period it landed in, in full, however long it was open before.

The second half of the rule is what keeps work in flight visible. Without it a period would only ever describe finished work, and a fortnight spent on a pull request that has not landed would show nothing at all.

Every pull request touching the period appears exactly once — nothing can be both finished here and still open — so the states below share one denominator.

[!NOTE] A pull request opened in this period and merged after it ends is not counted here. It counts in the period it merges in. That is the trade for a headline that says what shipped: the figure for a recent range keeps rising as work lands.

Pull request states

Where pull requests stand splits the pull requests the period covers by where each one stands now. It sits beside Where tasks stand and draws the same way, a bar of the shares over a list of the counts, so the two compare at a glance.

State	Meaning
Open	Still in flight, and something has happened to it recently
Stale	Open, not a draft, and untouched for three days
Draft	Deliberately not ready — counted separately so it never reads as stuck
Merged	Landed
Closed	Abandoned without merging

One pull request, one state, one denominator. Stale is the state that carries an action, so it is marked Needs a look whenever it holds any; the rest are context for it.

Where drafts count

A draft is work in progress, so it is kept out of anything that judges finished work:

It is never stale — a draft nobody has touched is not a problem.
It is not classified for complexity. Calling work in progress a quick win is premature, and an abandoned experiment would drag the team's typical effort down with it.
Closing one does not count against the merge rate. Opening a draft to try something and closing it is not abandoned work, and counting it that way makes a healthy exploratory habit look like churn.

It still appears in its own slice and in size figures — because both of those are simply true.

Flow

Every figure on this card describes the pull requests the period covers. The flow figures — merged, closed and merge rate — count only what finished inside it, so the card answers "what shipped here". The rest describe every pull request in the period, finished or not, because size and review evidence are true of a pull request whether or not it has landed.

One consequence worth knowing: a pull request that has been stuck since before the period is not counted here at all. Widen the range to count it; the Pull requests tab of the Work page lists it under Open or Stale whatever the range.

PRs merged — how many pull requests merged in this period, counted on the day they merged, with the merge rate beneath it. It counts something different from Tasks shipped at the head of the row: a task can take several pull requests, and a pull request need not name a task.
Reviewed — the share of pull requests somebody other than the author looked at. Needs the pull request reviews subscription to be complete; without it this counts only merges by a colleague and will read low. That counts a submitted review or a merge by a colleague: merging someone's work is itself an act of review, and it is the only trace left when a reviewer approves without comment. Read this one first: it is the difference between "our reviews are efficient" and "we mostly do not review". A pull request the author merged themselves is the one case with no independent evidence either way.
Review cycles — how many times a reviewed pull request went back and forth. One means it was reviewed and merged in a single pass. Counted while it is still open, not once it merges, so a pull request on its third round is visible now rather than afterwards.
Time to first review — shown beneath Reviewed, opened until somebody first looked. This is a team number, not the author's: it measures how quickly reviewers respond, so reading it as a statement about whoever opened the pull request blames the wrong person.
Merge rate — shown beneath PRs merged, merged against abandoned, among what finished here. Persistently low means work is being started that should not have been.

A round of review feedback is the system working, not waste — teams in the top quartile still average slightly more than one cycle per pull request. It is sustained back-and-forth that is worth asking about.

Shipments and change lead time

Work is shipped when it reaches a delivery branch — the branches set as the project's delivery branches, main and master unless changed. Clocktopus does not watch deploy events, so shipped says where the work landed, not that your pipeline deployed it. The headline row opens with what shipped and how long a change took to get there. Work pushed straight to a delivery branch needs no pull request, so these stay in the row in a period with none.

Tasks shipped — the tasks whose work shipped in this period (see Where tasks stand), with the shipments that carried them beneath. A shipment is a push or pull request merge that brought commits onto a delivery branch for the first time. A promotion from develop to main carrying ten tasks and fifty commits is one shipment. Work that was already on a delivery branch does not count again when it moves to another one. With at least three shipments the board also shows their rate per week, and the pace verdict beside the figure is on how often shipments happen.
Change lead time — from a change's first commit being written to its last commit shipping, over the changes that shipped in the period. A change is the merged pull request its commits were written in — the first one, so a feature merged into develop and later promoted to main is timed from its first commit to the promotion — or, for commits that belong to no pull request, the push that brought them to a delivery branch. The board shows its median and 90th percentile, never an average: a few long-lived branches would drag an average far from anything typical. A change whose commits were written after they arrived (a rewritten date) counts as zero.

Merge commits count towards neither. The commits they merge arrive with them, and GitHub's push of a pull request's merge commit lands seconds after the pull request's own commits, so counting it would make one merge two shipments and add a lead time of zero.

Both cover the projects the board covers and every commit in them, whoever wrote it, on My work as on Team. Neither is a figure for a person. Narrow the project filter to see one project's; leave it empty for the organisation's. With fewer than three changes the board shows how many there are instead of a median.

The board's chart draws, for each day, the pull requests merged beside the tasks shipped. When pull requests merge into a branch such as develop, the merged bars come day by day and the shipped bars arrive together on the day a release reaches main; the work waiting in between is Ready to ship in Where tasks stand.

Where tasks stand

The headline rail's Tasks shipped counts the tasks whose work shipped in the period. Where tasks stand follows the tasks created in the period instead, and places each one at the furthest stage it had reached by the period's end:

Stage	By the end of the period
Not started	No commit or agent session
In progress	Commits or agent sessions, no pull request
In review	A pull request naming it opened, none merged
Ready to ship	A pull request merged, its work not yet on a delivery branch
Shipped	Its work reached a delivery branch
Cancelled	Cancelled in the tracker or in Clocktopus, or every pull request closed without merging, unshipped

Each task is counted once, so the stages add up to the tasks created and the largest is where work is piling up. Of the four stages before shipping, the one holding the most tasks is marked Bottleneck; on a tie, the later stage, since it is the one holding the others up. A large Ready to ship usually means pull requests merge into a branch such as develop and wait for a release to main; if work ships from another branch as well, add it to the project's delivery branches.

Both figures cover the projects the board covers. They are figures for the project, not for a person: on My work as on Team, a task counts whoever worked on it. With the project filter empty, tracker tasks no branch or commit has given a project yet are counted too. Only keys shaped like a task, such as BLA-12, count: a commit scope like ci or release is not a task.

Created is the tracker's own creation date. A key typed straight into a branch or commit, with no task behind it, is created when Clocktopus first sees it.

Beneath Tasks shipped in the headline row, created → shipped gives the median time from creation to shipping over the tasks shipped in the period, followed by its pace verdict in words. With fewer than three such tasks it is left out.

Pace against your usual

A figure on its own does not say whether the team is keeping its pace. Three figures carry a verdict beside them: ahead, on pace or behind, and no badge at all when there is too little history to say. Each compares the team with its own history, never with other teams or people, and never as a percentage change against the previous period: with a handful of deliveries a period, that mostly measures how busy the last one happened to be.

Figure	One item	Its value
Created → shipped	A shipped task	Creation to shipping
Change lead time	A shipped change	First commit written to its last commit shipping
Shipments	A shipment	Working days since the shipment before it, on the same projects

How the verdict is reached:

Recent. The last 10 items delivered before the end of the period, however long ago they were. Counting items rather than days lets a small team or a solo developer get a verdict too, over a longer stretch.
Usual. The items before those 10 that were delivered in the 12 weeks before them. When those are fewer than 20, the 20 items before the recent ten, as far back as a year. Every run of 10 consecutive items in it gives a value, and the usual range runs from the 10th to the 90th percentile of those values.
Verdict. Ahead or behind only when the recent value falls outside the usual range, so a change has to be larger than the baseline's own spread before it is called. With fewer than 10 recent items or 20 usual ones there is no verdict, and the figure shows no badge. Nor does a figure whose period shipped nothing: the recent items would all come from an earlier one.
Days away are left out. A calendar day with no tracked time in the projects is subtracted from every duration that spans it, so a week off reads as away, not behind. With no tracked time at all in the year, nothing is subtracted.
Values, not deltas. The board shows the recent value with its usual range — "every 1.2 working days · usual 0.8–1.5" — and never a percentage change.

Durations in the verdict are the team's own and use days away left out, so they can read shorter than the period's medians beside them.

Before the team has a usual range

Until there are enough items for a usual range, change lead time and shipments show the band the DORA annual survey (Accelerate State of DevOps Report 2024) places them in, from the last 10 items in calendar time. It is context from other organisations' answers, not a target, and it disappears once the team's own range exists.

Band	Change lead time	Deployment frequency
Elite	Less than a day	On demand, at least daily
High	A day to a week	Between daily and weekly
Medium	A week to a month	Between weekly and monthly
Low	Longer than a month	Less often than monthly

Shipments are DORA's deployment frequency. Created → shipped is not a DORA measure, so it gets no band.

Work complexity

Work complexity places the pull requests from Where pull requests stand, drafts aside, in one of five categories. Hover a category on the card for a one-line reminder of what it means.

Category	What it means	Worth doing
Quick win	Small and fast	Nothing — this is healthy throughput
Deep work	Sustained effort, little code	Protect it. This is the work that gets undercounted everywhere else
Heavy lift	Sustained effort and a lot of output	Check it was reviewable — big and slow usually travel together
Bulk change	A lot of output for very little time	Usually generated, vendored or a rename. Fine, but not throughput
Contested	Reviewed repeatedly, round after round	The requirements, not the developer. Ask what was unclear

What it is measured on

Effort against output. Effort is the time tracked against the work; output is how much came out of it. Both come from sources that both GitHub and Bitbucket provide, so the same work is classified the same way whichever host it came from.

Where a provider also reports the size of a change, that sharpens the output side. Where it does not — Bitbucket sends no size data at all — the pull request is placed on the other signals rather than being skipped or guessed at.

What it is deliberately not measured on

Lines of code, as the primary signal. A one-line fix found after two days of debugging is the hardest work on the board; a generated migration is thousands of lines of nothing. Ranking by diff size gets both backwards, and it is the easiest number on the board to inflate on purpose.

Size still contributes where it is available — it is genuinely useful for spotting a bulk change — but it can only ever add to the picture, never decide it alone.

Pull requests with no tracked time

Effort is the time tracked on a pull request's branch or, failing that, against the task it names. One with neither — its commits came from a fork, or were pushed to a branch Clocktopus never saw, and no time was logged on its task — has no effort to weigh, so it is left out of the categories rather than guessed at. The card says how many were left out.

Boundaries adjust to your team

What counts as a lot of effort or a lot of output is a boundary, and four hours means something different in embedded firmware than in a web app. So the boundaries start from published industry research and move to your team's own typical pull request once there is enough to go on:

Boundary	Starting value	Once five pull requests in view have tracked time	Never beyond
Effort	4 hours	Your team's median hours	1–16 hours
Commits	6	Your team's median commits	2–12
Lines	400	Your team's median lines changed	400–2,000

A pull request above the effort boundary is high effort; one above the commit or line boundary is high output. Three or more review rounds make it Contested whatever its effort and output.

Pull requests measured from the same branch or task count once towards the median, so one long branch cannot set the boundaries on its own. Lines only move once five pull requests reporting a size are in view.

How far each task has got

Clocktopus records when each task's work reaches each branch your pull requests merge into, and works out from that where the task stands. Both show on the Work page and on each task's page.

A task is a key. It comes from a commit's conventional-commit scope (feat(ACME-42): …), from the branch a commit was pushed to (feature/ACME-42-export), or from the pull request a commit belongs to. Where Linear or Jira is connected, the task also shows its title, its description, and when the tracker created it.
A task reaches a branch when its first commit does. A task that spans repositories counts once its first commit has arrived in every one of them that has a branch of that name.
A commit arrives when its pull request merges, or when it is pushed to the branch directly. Squash and rebase merges count through their pull request.
Promotions carry everything with them. When a pull request from develop into a release branch merges, every commit that had reached develop by then reaches the release branch with it, and so on to main. This holds however many commits the release carries, so a large release never drops tasks because the provider listed only some of them.
An arrival is never taken back. A later force push or revert does not move it.

A task's page shows where it sits now, with one badge per repository when it spans several:

A shared branch — one a pull request has merged into, or one of the project's delivery branches — once its work has reached one: the one it reached most recently.
Before that, its open pull request, as source → target.
With no pull request open, the branch its work was last pushed to.

The last two are drawn muted: the work is not on a branch anyone else shares yet.

Where each task stands

Each task shows a stage, worked out from what happened rather than from a status someone set:

Stage	When
Created	The tracker has it, and no work has started
In progress	A commit carries its key, an agent session worked on it, or a pull request naming it is open as a draft
In review	A pull request naming it is open and ready for review, in its branch or, when the branch names no key, its title's `type(KEY-1):` scope. A draft counts from when it is marked ready
Ready to ship	That pull request merged, and the work has not reached a delivery branch yet
Delivered	Its first commit reached one of the project's delivery branches
Cancelled	The work was never delivered, and either it was cancelled, in the tracker or in Clocktopus, with no work after the cancel (a commit, an agent session, a tracker start, a pull request offered for review or merged), or every pull request naming it closed without merging and no commit, agent session or tracker start came after the last close

An agent session works on a task when its branch names the key, when one of its commits carries the key, or when the session tied itself to the task through the MCP server (link_session, which the agent skills call when it picks a task up). A session can work on several tasks; its spend is shared between them as the AI agents page describes, so the tasks' agent costs add up to the session's.

Delivery branches are set per project, in Project settings, as branch names separated by commas, where * stands for any characters. Left empty, they are main and master. A team using git flow keeps main; one that deploys release branches sets release/*. A task spanning repositories is delivered once its work has reached a delivery branch in each of them that has one.

Merged → delivered is the time from a task's last merge to its delivery: how long finished work waits for UAT or a release. A pull request straight into a delivery branch makes it zero.

Pull requests merged before branch arrivals were recorded are included, with their commits as the pull request saw them, and promotions carry them on. A release merged into main without a pull request is read from the push alone, which lists only some of the commits in a large one.

The Work page

Work in the sidebar has two tabs, Tasks and Pull requests, each with its own address (/{org}/work/tasks and /{org}/work/pull-requests). Both share the filters at the top: the date range, and a project dropdown that narrows the lists to the projects you pick. The project selection is the one the dashboard and reports use, so it carries between them, and switching tabs keeps both filters.

Tasks

The Tasks tab lists the organisation's tasks in one list, grouped by stage, each group with its own coloured status icon:

Ready to ship, In review and In progress: the tasks in flight, with the date each reached its stage. A task an agent is working on right now comes first in its group, with whose session it is. An agent counts as working while its session has not ended and sent telemetry in the last 15 minutes, so a session whose end was never reported drops off by itself. A task shows here while it has a commit or agent session from the last 60 days, or an open pull request.
Stale: in progress, but with no commit, time entry, pull request activity or agent session telemetry in the last 3 days, and no agent working on it. Each shows the date of its last activity. Any new activity moves it back to In progress.
Todo: created, with no commit, pull request or agent session yet, newest first, with how many there are. It loads 100 at a time; Load more shows the next 100, up to 1,000. Tracker tasks no project has claimed yet are included, unless projects are picked in the filter.
Delivered: reached a delivery branch in the selected period. How long each took to deliver is on its own page.
Cancelled: cancelled in the selected period, in the tracker or in Clocktopus, or with its last pull request closed without merging.

The date range at the top bounds only Delivered and Cancelled; the other groups show what stands now. Pick an earlier period to see what was delivered then.

Groups with nothing in them are hidden, and each group collapses; Ready to ship, Stale, Todo, Delivered and Cancelled start collapsed. Going back to the list from a task keeps the groups you opened and where you had scrolled.

Tasks move only on git signals, so an organisation with no repository connected sees a prompt to connect one in place of the list, and one whose repositories have sent no pull request yet sees a banner: without pull request events nothing reaches In review or Ready to ship. How tasks arrive and how your coding agent picks them up is in Agent skills. A task known only from a branch, commit or time entry shows its key alone until its tracker sends a title.

Each row opens the task, links its pull requests and shows the hours spent on it so far, everyone's, people's and agents' together. Owners and admins also see what it cost beneath them: people at cost rates plus agent spend. Members see the hours without amounts, which are for owners and admins, as on budgets. A + after an amount means some agent sessions reported no spend, so the real figure is higher. Hide amounts in the account menu masks them here and on every other page. A task with a kind shows it as a chip (Bug, Feature, Improvement or Tech, from its Linear labels or Jira issue type, or set in Clocktopus), and a refined task a small checklist mark: its open questions are settled. The task's page shows both too. Any task not yet delivered can be cancelled from its row's menu, a Linear or Jira task as well as one created in Clocktopus; the task in the tracker is left as it is. A cancelled task, cancelled here or in the tracker, moves back as soon as work on it resumes: a commit, an agent session, or a pull request offered for review or merged. Above the lists, each active goal shows its tasks by state: Done (merged, struck through) and To do (the open tasks, in the goal's order), with up to three keys for Done and five for To do and a count of the others. A refined key carries the same checklist mark, and each key's tooltip gives its stage, kind and whether it is refined. It also shows how many of its tasks are done. Once every one has merged, the goal reads Ready to ship instead, and once every one has reached a delivery branch the goal closes itself and leaves the page. A goal with no tasks, or only cancelled ones, stays open. Cancelled tasks are left out of the card and the count until the goal releases them. Close goal in a goal's menu closes it by hand, once its outcome is reached some other way or it is dropped; its tasks are left as they are. The page updates as webhooks, agent telemetry and MCP writes arrive. With projects picked in the filter, only those projects' goals show.

Pull requests

The Pull requests tab lists the pull requests of the projects you can see, grouped by status like the Tasks tab:

Open: open and ready for review, newest first.
Draft: open as a draft, not yet offered for review.
Stale: open and ready for review, but with no push, review or comment in the last 3 days, ordered by their last activity.
Merged: merged in the selected period.
Closed: closed without merging in the selected period.

As on the Tasks tab, the date range bounds only Merged and Closed; the open groups show what stands now. Stale, Merged and Closed start collapsed. Each row opens the pull request on GitHub or Bitbucket, and shows the task its branch names (linked to the task's page), how many reviews it has had, the lines it adds and removes (GitHub only), its project, its author, its work complexity as a coloured dot (hover it for the category) and the date that matches its group. The complexity is judged against the project's pull requests from the last 90 days, as on a task's page; a draft, or a pull request in a project you are not a member of, has none. A pull request whose repository is linked to no project is not listed. The tab updates as pull request webhooks arrive.

One task

Opening a task on the Work page's Tasks tab shows it end to end. To jump to one from any page, press Ctrl+K (⌘K on a Mac) or choose Search tasks in the sidebar, then type its key or words from its title or summary: the best matches come first, a misspelt word still finds a title with the word spelt right, and delivered and cancelled tasks are included. With nothing typed, it lists the tasks in progress and in review.

Where it stands: its stage and how long it has been there, with its tracker link and its project.
Description: a Clocktopus task's summary, or the Linear or Jira description, rendered as Markdown; any HTML in it shows as text. A tracker's task gets its description the next time the tracker sends an update for it.
Cost: people's hours, agents' runtime (each session's active time, shared between its tasks as its spend is), the two together, and how long it took from created to delivered. Owners and admins see the amounts beneath: hours at each person's cost rate on the day (naming any hours with no rate), the agents' spend and the total.
Timeline, newest first: created, when work started (its first commit or agent session), each time entry filed against it with who logged it and for how long, each pull request opened and merged, delivered or cancelled, and each agent session as a span from its start to its end. Created is the tracker's date, or when Clocktopus first saw the task if the tracker never sent one, so it can come after the first commit. Each agent session on the timeline shows this task's share of its runtime, and for owners and admins its share of its spend.

People's time reaches a task through the key in a commit's message, or, when the message has none, through the branch or pull request the commit came from. Time you were clocked in that no commit accounts for goes to the task your agent sessions worked on most in that window.

How to read these

The metrics are built so that gaming any one of them degrades another, and they should be read the same way.

Volume is context, never a score. Commit counts and pull request counts appear beside flow and rework figures on purpose. On their own they reward the wrong behaviour within a sprint.
A dash is not a zero. Where there is not enough to say something honest, the figure is withheld rather than estimated. A median drawn from one pull request is not a measurement.
Compare to the team median, not to each other. It sits beneath every column for exactly this reason.
Ask, do not conclude. A stale pull request or a contested one is a prompt for a question. None of these numbers know about the outage, the customer call or the afternoon spent unblocking somebody else.

Known limits

Worth knowing before the numbers surprise you:

Nothing backfills. Coverage starts when you subscribe to the events.
A period's figures keep moving. Work opened in a period lands in whichever period it merges in, so a range covering this week fills in as this week's pull requests close.
Bitbucket reports no change size, so those pull requests are placed without it. This is by design, not a gap in the data you can fix.
Pull requests from forks carry no commits we can see — the pushes go to the fork, not to your repository — so their effort cannot be measured.
Bot authors are excluded so a dependency bot cannot dominate the board.
Only reviews that reach us are visible. A pull request reviewed in person, over chat, or on a provider we are not subscribed to looks identical to one nobody read. Where no review has come through at all, coverage reports as unknown rather than 0% — absence of a record is not evidence of absence.
Review cycles count only pull requests we saw a review on. One merged without a recorded review had no cycles, which is not the same as having had a clean single pass, so it is left out rather than counted as 1.
Time tracked against the work is what makes it measurable. A pull request with no tracked time is shown as unmeasured rather than counted as zero effort.