Use project Metrics

Open Metrics from a project to use one consistent place for delivery measures as they become available. Metrics is separate from the project home and always stays within the current project.

Use Date range in the page header to choose Last 7 days, Last 30 days, Last 90 days, or All time. On a narrow screen, the control stacks below the page title. The default is Last 30 days. Your selection is stored in the page URL, so refreshing the page, moving back or forward, or sharing the URL preserves it. An unsupported URL value safely returns to Last 30 days.

Day ranges use UTC calendar boundaries. They include the current UTC date and end at the next UTC midnight. This keeps later metrics consistent for people viewing the same project from different time zones.

Completed tasks in range counts Coding-agent and Person project tasks that are currently Done, are included in metrics, and have a durable completion time in the selected UTC range. It counts tasks, not work runs, commits, task size, or a productivity score. If a task is reopened, it is not counted again until it is completed again.

A task that is Closed is not delivered work. Closing clears its completion time, and a Closed task stays out of throughput, AI work-time, human review-time, and accepted-without-follow-up metrics even when its earlier work runs or review history remain visible.

Use Exclude from metrics while editing a task when it should remain visible and keep its current lifecycle and history but not contribute to reporting. The change applies immediately and retroactively to every task-derived metric on this page, including throughput totals, buckets, comparisons, coverage, duration distributions, and accepted-without-follow-up outcomes. Including it again restores any evidence that still meets the metric's other rules. A Closed task remains excluded by its lifecycle independently of this choice.

When the immediately preceding range of the same length has completed-task data, the card places the signed difference as text beside the completed-task count and names that range. An increase is green with a plus sign, a decrease is red with a minus sign, and no change remains neutral. The sign and words keep the comparison understandable without relying on color. Supporting text gives the previous count. The card omits a comparison when that earlier range has no completed-task data, including for a new project, and All time has no matching earlier range. These colors show the direction of change; a low or high count is still an observation, not a target or ranking.

The trend uses daily UTC buckets for Last 7 days and Monday-starting weekly UTC buckets for longer ranges. Its table lists each bucket and count, including zeroes in a selected finite range; the values themselves identify their UTC boundaries.

Accepted without follow-up shows the percentage of completed tasks whose first trustworthy submitted work run was accepted with no earlier recovery, requested follow-up, or fresh restart. The card states the accepted-task numerator and known-review-history denominator directly. It also reports completed tasks whose older or incomplete history cannot be classified reliably.

A task stays in the denominator but not the numerator when review requested follow-up, review chose Start fresh, an incomplete run was recovered before the accepted submission, or the task has more than one submitted run. This includes another submitted run after a task was reopened and completed again. Recompletion still contributes at most one task in the period, using its current completion time. A direct Person completion has no submitted review history, so it is reported as unknown rather than treated as a failed first pass.

The trend uses daily UTC completion buckets for Last 7 days and Monday-starting weekly buckets for longer ranges. Each bucket exposes the accepted count, known-history count, and percentage in an accessible table. A bucket without known review history shows N/A, not zero percent.

This measure combines task clarity, Coding-agent or Person execution, the working environment, and review rigor. It does not isolate AI performance, rate reviewers, establish work quality, or set an acceptance target. The page therefore uses no red or green judgment for this percentage.

AI work time per completed task measures the total recorded Coding-agent work time for tasks that are currently Done in the selected range. Each completed task with eligible Coding-agent work is one sample. Metrics adds the complete start-to-done duration of every eligible initial or review follow-up Coding-agent work run into one task total before calculating the project average, median, or p90. Person work runs do not add time or become zero-duration observations. Review follow-ups increase that task's total; they do not become separate samples.

The large value is the average. Median shows the middle of the observed task totals. The card's definition helper explains that p90 is the duration that 90 percent of included tasks took or less. One included task is enough to show the distribution, and a valid zero-duration submission remains a real zero-second result.

The trend groups task totals by each task's completion date. Last 7 days uses daily buckets; longer ranges use Monday-starting weekly buckets. The accessible table lists average, median, p90, and the eligible task count for every bucket. A bucket with no eligible task shows N/A for those duration statistics; the accessible name explains that the values are unavailable rather than suggesting zero-duration work.

AI work time starts when the coding-agent process records that it began and ends when the coding agent marks its work done and submits it for review. It excludes queue time before the agent starts and review time after submission. Pauses, approval waits, or blocked time inside the recorded interval are not separately removed. It is not end-to-end task cycle time, an effort estimate, a productivity score, or a target. A higher or lower duration is context, not an automatic judgment.

Metrics first requires the task to be included in reporting. It then includes a Coding-agent work run only when it was submitted normally, remains eligible for metrics, has both timestamps, and does not end before it starts. Each included run contributes its complete elapsed time from agent start until work is marked done; Metrics does not select fragments within an interval. It then adds every included run for the same task into that task's total. It does not automatically trim valid long tasks; average, median, p90, and sample size keep their tail behavior visible.

Human review time per completed task measures configured organization working time from each eligible Coding-agent or Person work submission to its first review resolution. Accepted, Follow-up requested, and Started fresh each resolve a review interval. If a completed task has several resolved review runs, Metrics adds their working-hours durations into one task total before calculating average, median, and p90. The card also shows the number of completed tasks included in the distribution.

The calculation always uses the owning organization's time zone and weekly working-hours calendar, regardless of the viewer's local time zone. A review submitted after Friday's working hours and resolved on Monday counts only the configured time that overlaps the interval. Daylight-saving boundaries follow the organization's local calendar and are intersected in UTC so the same durable timestamps produce the same duration for every viewer. Public holidays, paid time off, individual schedules, split shifts, project overrides, and raw wall-clock review time are not included.

The trend groups per-task review totals by task completion date, using daily UTC buckets for Last 7 days and Monday-starting weekly UTC buckets for longer ranges. Its accessible table lists the server-provided average, median, p90, and included-task count. Empty buckets show N/A for duration statistics, with an accessible name explaining that the values are unavailable rather than zero.

An unresolved review does not accumulate time through now and does not enter the distribution. Older work whose submission or first resolution is not known is also excluded. A task can still be included from its trustworthy resolved intervals while another interval remains excluded from the arithmetic. A resolved interval with no overlap with working hours is a valid zero-second observation.

When working hours are not configured, only this metric is unavailable; completed-task throughput and AI work time remain usable. The card shows N/A, with an accessible name explaining that working hours are not configured. Organization owners and admins can follow the card's link to the Working hours section of Organization Settings. Other project members see guidance to ask an owner or admin. alterac.ai never invents a default schedule.

Human review time is not reviewer effort, an individual-performance measure, a service-level target, or complete task cycle time. A higher or lower value is context rather than an automatic judgment.

Zero completed tasks is an accurate result and remains visible. When there are no completed tasks in the selected period, the AI work-time and human review-time cards show N/A with No completed tasks yet. Their accessible names explain that this is not enough data yet, rather than a zero-duration result. If completed tasks exist but their AI work time or review time cannot be calculated, the cards instead say Unavailable so that a data problem remains distinct from a new, empty, or unconfigured period.

Each value includes a definition and sample context. Charts retain a textual or tabular way to understand their values, and wide data tables remain keyboard accessible on narrow screens.

Return to the project overview for current work, or organize project tasks before reviewing future delivery measures.