Reports
- Who can use it
- Everyone, within what your role can see
- Where
- Left navigation, grouped by category
Each report answers one question a delivery review asks. Pick the report by the question, set the date range in the filter bar, and read the chart and the table behind it. Every number respects your role: you only see the people your workspace’s visibility settings allow.
The navigation groups reports into Home, AI Impact, Quality, Predictability, Efficiency and Industry Benchmarks. Terms like cycle time and lead time are defined in the metric glossary.
PR Workflow
Question: Where does a pull request wait, and how long does it take to ship?
Find it under Efficiency → PR Workflow. It shows:
- Cycle time (open to merge) week by week against a target line, with a percentile view (p10, median, p90) for the spread behind the average.
- Lead time by stage: first commit to open, open to first review, first review to merge, and merge to deploy once your workspace tracks a production deploy. Until then, merge to deploy reads “Not tracked”.
- Long lead time PRs: the merged pull requests whose lead time is over target, longest first. The title opens the pull request.
Click a week in a chart to open the pull requests behind it. Bot-authored pull requests are left out.
CI Analytics
Question: Is CI slowing us down, and where does it fail?
Find it under Efficiency → CI Analytics. It has four sections:
- Pipeline duration and queue time: mean and median run time per day, and how long a first attempt waits for a runner.
- Failure rate: the share of finished runs that failed, week by week. Cancelled and skipped runs are not counted.
- Flaky tests: jobs that both failed and passed on the same commit. GitHub reports no test results, so a flaky test here is a flaky job.
- CI minutes: runner minutes by team.
The team and group filters do not narrow this report. It opens on the last four weeks.
Bug Creation, Bug Resolution and Bug Workload
Question: How much of what we ship needs fixing, and do we fix bugs as fast as we find them?
These three live under Quality. A bug is a ticket with a bug label in your ticket mapping. Tickets count for the person they are assigned to, so unassigned bugs are in no count.
- Bug Creation: the change failure rate (the share of production deploys that failed or were followed by a revert or hotfix) and the rework rate (bugs created per ticket completed).
- Bug Resolution: the time from report to done, and bugs created against bugs resolved each week.
- Bug Workload: the share of completed tickets that were bugs.
An org admin sets which labels mean “bug” under Admin → Ticket mappings.
Predictability
Question: Do our sprints deliver what they commit to?
Find it under Predictability → Predictability. Per team, over the cycles that ended in the date range, it shows:
- Done vs. committed: points done as a share of points committed at the start.
- Rollover: the share of the previous cycle’s scope left unfinished.
- Scope creep: scope added minus scope removed after the cycle started.
- Cycles: every cycle with its points.
Teams here are teams in your ticket tool (Linear), so the filter bar’s team and group do not narrow this report.
Initiatives
Question: Is each initiative on track, and when will it finish?
Find it under Predictability → Initiatives. It lists each initiative with its progress (tickets and points done), a forecast finish date based on the last 28 days of completions, and the pull requests linked to its tickets. Initiatives come from Linear. The figures are a current snapshot, so the date range does not apply.
Managers and org admins can open this report. Developers cannot.
Collaboration Network
Question: Who reviews whose work, and is review load spread fairly?
Find it under Efficiency → Collaboration Network. It has three parts:
- Between teams: arrows from the reviewing team to the team whose pull requests they reviewed. Thicker arrows mean more reviews.
- Between people: the same, for individuals, only where your visibility setting lets you see both ends.
- Review load: the share of each team’s reviews that each reviewer carried.
The graph is in name order. DevGlimpse does not rank people, and teams below your minimum group size are left out. The Review load section is visible to managers and org admins. Team and group pages also have a Review load section with reviews given, reviews per pull request opened and average review latency for the team as a whole.
Pulse surveys
Question: How do developers feel about the work, next to how it is going?
A short monthly pulse asks two or three statements on a 1 to 5 scale, from Strongly disagree to Strongly agree. Answers are stored with the person’s teams and groups, never with their name. Results show on a team or group page under Satisfaction, only after the pulse has closed and only when enough people answered.
To set it up (org admin):
- Open Admin → Pulse survey.
- Turn on Run a monthly pulse.
- Set Opens on day (UTC) (1 to 28), Stays open for (days) (3, 5, 7, 10 or 14) and Minimum responses per team (5, 8, 10 or 15).
- Pick two or three questions from the library. Each is tagged Satisfaction, Well-being, Efficiency and flow, Collaboration or Performance.
- Select Save schedule.
While a pulse is open, every member sees a Monthly pulse card at the top of the page. They choose a score for each statement and select Submit, or select Not now to hide it.
Report builder
Question: The one nobody predicted.
Build your own report under Home → Report Builder:
- Pick a Metric, such as PRs opened, PRs merged, Commits, Reviews given, Lines changed (merged PRs), Median cycle time, CI runs, Failed CI runs or Median CI run duration.
- Choose Group by and optionally Then by, for example Week, Repository, Contributor, Provider, PR state or Workflow.
- Choose a Chart: Table, Bar chart or Line chart.
- Select Preview. The filter bar’s dates, repository and contributor apply.
- Type a Report name and select Save report.
Saved reports appear in the navigation under Custom reports. Open one and select Delete report to remove it. A saved report always shows only the people your role can see.