What it is
Operation View is a panel on each iteration showing engineering delivery metrics sourced from your connected repositories: how pull requests are moving through review, how often you're deploying, and how much code changed.
How to read it
Pull requests are grouped into five buckets by age and state: closed, fresh, aging, stale, and critical — the further along, the longer a PR has sat without merging. Release metrics show deployment counts and the percentage of failed releases for the iteration. A "Lines of Code" watermark gives a rough sense of change volume. Stage timers (Sent → Seen, Seen → Approved, Approved → Merged, Merged → Deployed) show where PRs spend the most time. A separate FCT (Flow Cycle Time) figure, shown in the sprint summary rather than Operation View itself, is the end-to-end version of those stage timers: the sum of the sampled stage medians, in days, from a PR being sent to its change being deployed. When an iteration has no sampled stages yet, the sprint summary shows a dash rather than a number — FCT is never estimated.
How time to restore is computed
Time to restore measures how quickly your team recovers when a deploy goes wrong. Everview derives it from your deploy stream — workflow runs and deployments — with these rules:
- Per repository. A failure in one repository is only ever restored by a later success in the same repository.
- Cross-source within the stream. A failed workflow run may be restored by a successful deployment (and the reverse) — recovery is recovery, whichever mechanism delivered it.
- Releases don't count. A published release is a publication, not a deploy outcome, so releases neither fail nor restore anything.
- Median hours per iteration. Each failure pairs with the next success after it; the iteration's figure is the median of those gaps, in hours.
When an iteration contains no restored failure — nothing failed, or a failure has no later success yet — Operation View shows a dash rather than a number. A dash means "no restores this iteration," which is not the same as restoring instantly; the view never renders it as zero.
What to do about it
A growing count of aging or stale PRs is an early warning independent of sprint Momentum — code can be stuck in review even when the sprint looks healthy. Use the stage timers to find where PRs are actually stalling rather than guessing. See Spotting Delivery Bottlenecks with Operation View for combining this with sprint execution data.
Operation View's underlying data refreshes as GitHub sends webhook events for new pull requests, deployments, and commits — you don't need to manually resync a connected repository. For engineering signal at the repository level rather than the iteration level — CI success rate, security alerts — see Understanding Repository Health.