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 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.

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 throughput totals, buckets, comparisons, coverage, and the task-derived duration metrics on this page. 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.

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 is one sample. Metrics adds the complete start-to-done duration of every eligible initial or review follow-up work run into one task total before calculating the project average, median, or p90. 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 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 included 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. 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. AI work time is different: if no completed task has recorded AI work time that can be included, its distribution is unavailable rather than a zero-duration success.

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.