Keeping team-level GitHub delivery metrics in Confluence as Compass moves to DX

[#1]

If your team leaned on Compass for a free, native DORA-style baseline, you have probably seen the news: Compass is moving to DX. That shift is a good moment to ask a practical question - where will your team's delivery metrics live next, and do they need to live in a heavyweight platform at all?

This article is a hands-on look at one lightweight option: rendering team-level GitHub delivery metrics directly on the Confluence pages your team already reads. The goal here is education, not a hard sell - so I will be clear about what this approach does, what it does not do yet, and who it is actually a good fit for.

Disclosure: I work at Move Work Forward (MWF), the vendor behind the "GitHub Links for Confluence" app described below. I have tried to keep the framing honest and useful regardless of which tool you end up choosing. We use it internally also.

What's changing

Atlassian has announced that Compass is entering its next chapter and moving toward DX, following Atlassian's acquisition of DX. For many teams, Compass was the easy, no-cost way to get a native DORA-style baseline sitting alongside the rest of their Atlassian tooling. You can read Atlassian's own announcement here: https://www.atlassian.com/blog/announcements/the-next-chapter-for-compass

The short version: the free, native baseline that a lot of smaller teams quietly relied on is being folded into a more enterprise-oriented DX direction. If that was your setup, it is worth thinking now about where your metrics go next.

Who this affects

This change lands hardest on a specific group: smaller and mid-sized engineering teams who used the free DORA-style baseline, found it good enough, and are not going to buy into an enterprise-grade developer-experience platform to keep three or four numbers visible.

If you are a 5-to-30-person engineering org, a single squad, or a team that just wants to glance at cycle time and throughput in a sprint review, an enterprise DX deployment is almost certainly more than you need - and more than you want to budget for.

A lightweight approach

Instead of sending people to a separate metrics platform, render the metrics where your team already works - on a Confluence page. With the Engineering Reporting feature in "GitHub Links for Confluence," you drop a macro onto a page and it renders team-level GitHub delivery metrics live. Today that covers three delivery metrics plus one useful breakdown:

• PR Cycle Time - how long pull requests take to move from open to merged.
• PR Throughput - how many pull requests your team is shipping over a period.
• Review Latency - how long PRs wait before they get a first review.
• AI-assisted vs human-authored split - a team-level view of how much of your PR volume is AI-assisted versus human-authored.

These are DORA-style delivery metrics - useful signals about flow and review health - presented on the page your team already opens for sprint reviews, retros, or a team handbook.

How it works

• Paste and render. Add the macro to a page, point it at the team scope you want, and it renders. No separate dashboard to build or maintain.
• Computed live from the GitHub API. Numbers are calculated on demand at view time, so the page reflects current activity rather than a stale export.
• Nothing stored. We store no code or PR data - metrics are computed live and displayed; your source and PR content is not copied into the app.
• Reuses your existing GitHub connection. If you already use "GitHub Links for Confluence," there is no new integration to set up.
• Team-level by design. These describe how a team is delivering. They are not per-developer scorecards, and they are not meant to be.

Set it up in 3 steps

1. Confirm your GitHub connection. If you already use "GitHub Links for Confluence," you are set. If not, install the app and connect GitHub once - the reporting feature reuses that connection.
2. Add a reporting macro to a Confluence page. Edit the page, insert the macro for the metric you want, and choose the team scope and time period.
3. Publish and review. The metrics render live and refresh against the GitHub API, so your sprint-review or team page stays current without manual updates.

Honest scope note

• This is DORA-style, not full DORA. It covers cycle time, throughput, and review latency. It does not yet include Change Failure Rate or Mean Time to Restore, so I would not call it a complete DORA implementation. If those are essential to you today, factor that in.
• Team-level only. By design, no per-developer breakdowns. If you need individual-level reporting, this is not that tool - intentionally so.
• No data hoarding. We store no code or PR data; metrics are computed live.

If you need the full four-metric DORA picture or per-engineer analytics, an enterprise platform may genuinely be the right call. If you mainly want a few honest team-level signals visible where your team already reads, this lightweight approach is likely enough.

Learn more

• Deep-dive article (the "why" and full walkthrough): https://www.moveworkforward.com/blog/compass-alternative-dora-metrics-in-confluence
• Help-center guide: https://help.moveworkforward.com/GL/github-links-for-confluence-cloud
• Marketplace listing: https://marketplace.atlassian.com/apps/1216106/github-links-for-confluence

The Engineering Reporting feature is included in the app at the standard subscription - no separate add-on.