Stats and Insights

Stats

On Pro, each board has a Board / Stats switch in its header. Stats shows how work has moved through the board over the last few weeks. Free plans don't have Stats, and the switch isn't shown.

Stats only counts what you can see: confidential issues you don't have access to are left out.

Choosing a range

Pick 4 weeks, 12 weeks or 26 weeks. Weeks run Monday to Sunday (UTC), and the last one is the week in progress. A range is greyed out until GitGumbo has enough history to fill it ("Not enough history yet for this range").

How far back history goes depends on your plan: 90 days on Pro and 180 days on Team. That's why 26 weeks is never available on Pro.

The four tiles

• Merged: merge requests (pull requests on GitHub) merged in the range.
• Closed: issues closed in the range.
• Median cycle time: how long merge requests take from being opened to being merged, in days. It is the average of each week's median, over the weeks that had merges.
• Open work: how many issues are open now.

Merged and Closed also show a percentage: the change from the range of the same length just before it. Green means more, red means fewer. The percentage only appears when GitGumbo has history for that earlier range, so on Pro you'll see it on the 4-week view.

The charts

• Throughput: merge requests merged and issues closed, per week.
• Cycle time: the median and the 90th percentile, in days from opened to merged, per week.
• Column distribution: open issues by column.
• Age of open work: open issues by how long ago they were opened.
• WIP over time: how many open issues sat in each column, week by week.
• Contributors: reviews, issue closes and merges per person.
• Review activity: approvals and changes requested, per week.

A few things to know:

• Columns means label columns. Column distribution and WIP over time only understand columns made from labels. On a board whose columns are statuses, people or milestones, every issue shows as "No stage" in the distribution, and WIP over time stays empty. Boards with more than 8 columns fold the rest into "Other".
• GitLab reports approvals only. GitLab has no "changes requested" review state, so Review activity on a GitLab project only shows approvals.
• Every chart has a data table that screen readers can read.

Filling in history

When you add a project, and whenever Full Sync runs, GitGumbo imports the issues and merge requests closed in the last 90 days. That is enough for Throughput and Cycle time straight away.

WIP over time, Contributors and Review activity need more detail. Until they have it, they carry a "History still building" badge. To fill them in, choose Build full history above the tiles. It fetches your plan's full depth of history bit by bit, so it takes a few days on a busy project, and the charts fill in as it goes. If it fails you can Retry. After an upgrade gives you a longer history, the banner offers Rebuild history. You need permission to edit the project's issues to start it.

What's kept

History older than your plan keeps (7 days on Free, 90 on Pro, 180 on Team) is deleted every night. If you move to Free, your chart history is cut to 7 days, and upgrading again doesn't bring it back. Your cards are never deleted: this only affects the history behind the charts.

Insights

Insights is coming with the Team plan. Team isn't on sale yet; you can join the waitlist on the Pricing page. Once your firm is on Team, Insights appears in the sidebar.

Insights is a single list of the open issues and merge requests that look stuck, across every project in your firm. It only shows what your own account can see.

Why something is listed

Each item carries one or more reasons:

• Idle: nothing has happened for at least the number of days you set (3 by default). This is the only reason an issue can have.
• Stale draft: a draft merge request that has been idle that long.
• Changes requested: a reviewer asked for changes. GitHub only, because GitLab doesn't record who requested changes.
• Pipeline failing: the pipeline failed or passed with warnings.
• Conflicts: the merge request has merge conflicts.
• Unresolved threads: review threads are still open.
• No reviewer: nobody has been asked to review.

Items are grouped by project, most idle first. Turn on Show all open work to see everything that's open, stuck or not. The list shows up to 1,000 items; if your firm has more, it says so.

Filtering

Narrow the list by Projects, Reasons, Assignee (for merge requests, the author or a reviewer) and Idle ≥ N days.

You can Save the current filters for yourself. Admins can also Share with team, marked with ★ in the Saved filters list, and Set as team default.

Managing saved filters

Choose Manage filters to see every saved filter you can use: your own, and the ones shared with the team. The team default is marked Team default.

• Rename a filter. Names can be up to 100 characters.
• Delete a filter. You're asked to confirm first. Deleting the filter you're looking at doesn't change the list in front of you.
• Make team default or Clear team default on a shared filter. There is only one team default, so making a new one replaces the old one. The change applies the next time Insights is opened, not to the view you have open now.

You can change your own filters. Only admins can change shared filters or the team default; everyone else sees shared filters without the buttons. Managing a filter changes its name or whether it's the default, never the filters it saves: to change those, set them up again and Save.

When you open Insights, members start on their own work: issues assigned to them and merge requests they wrote or are reviewing. Admins start on the team default, or on everything if there isn't one. A member with no linked GitLab or GitHub account has no username to filter by, so they start where admins do.