A metric looks wrong. Before assuming a bug, walk through this checklist — most "wrong" metrics turn out to be configuration issues.

Is it actually wrong, or just unexpected?

The most common case: the metric is computed correctly but reflects something you didn't realize was happening. Click Show details on the metric card to see the underlying items. Often the data tells a true story you weren't prepared for.

Step 1 — Check the time range and filters

Make sure the date range is what you expect.
Clear all filters and re-run. If the number changes, a filter was hiding part of the population.

Step 2 — Check status mappings

Most flow metric errors trace back to status mappings:

If a state is misclassified as "active" when it should be "waiting", cycle time will look too long.
If "done" isn't the right terminal status, throughput will be wrong.
Open the integration's status mapping under Administration → Productivity Tools and verify each status.

Step 3 — Check user and team mappings

Unmapped users contribute zero to per-team metrics.
Bots or system accounts mapped as humans inflate activity numbers.
Verify mappings in Administration → Users.

Step 4 — Check the integration's data quality

For DORA: confirm which deployment source your organization uses (Settings → Modules → Performance Delivery). On the default source, Deployment Frequency and Change Failure Rate are derived from merged pull requests — a repository whose PRs aren't syncing will read low.
For flow: do Jira issues have proper status-change history? Bulk-edited issues sometimes lack history rows.

Step 5 — Just switched to GitHub deployments?

If Deployment Frequency or Change Failure Rate dropped to zero or looks thin right after turning on Measure deployments from GitHub:

Look for the "Bringing in your deployment history" notice on the Software Delivery Performance tab. The backfill is still running — the charts fill in as data lands, and the notice clears within 24 hours at the latest.
If the notice is gone and the numbers are still low, check that your pipeline actually creates GitHub deployments (or a deploy check run on release tags) and reports their final state. A deploy that never reports back is invisible to both metrics.
Only production deployments count. If your environments aren't marked as production in GitHub, Leanmote falls back to counting all deployments — which can make the number look higher than your actual release cadence.
Don't compare across the switch. Merges and deployments are different events, so a step change at the switchover date is expected.
Turning the setting back off goes back to counting merged pull requests immediately; the deployment history Leanmote captured is kept.

Step 6 — Compare to a known-good period

Switch the date range to a period where you know what the metric should be. If that range looks correct, the issue is data-source-specific to the new range. If both look wrong, the issue is configuration.

When to contact support

If you've worked through the steps above and the metric still doesn't reflect reality, reach our team via the Intercom Messenger. Include:

The exact metric and dashboard.
The time range and filters applied.
The expected vs. observed value with a sample of items if possible.

Missing data after connect
Metrics methodology overview (in leanmote.github.io/docs)
Working with the Leanmote API

Why a metric looks off