Metrics Settings

Last updated: October 27, 2026

Metrics settings control how Span calculates and displays engineering metrics across your organization. You find them in Settings → Metrics (under Global). Changes apply organization-wide and show up after the next metrics sync.

Why it matters

  • For admins: filtering out bots, CI repositories, and generated files keeps your metrics about human engineering work.

  • For leaders: consistent definitions (what counts as a test file, an incident, or a weekend) make numbers comparable across teams.

How it works

Each setting sits on its own card. Saving one shows "Settings have been saved. Metrics will update on the next sync." Every setting applies to the whole organization. There are no per-team or per-person overrides.

Data exclusions

Use these to filter out noise such as bots, CI repositories, or auto-generated files.

  • Ignore Repositories: exclude repositories from all metrics with a regular expression. Example: ^ci-.* excludes every repository starting with "ci-". Use it for CI/CD pipelines, archived repos, or any repository that shouldn't count.

  • Ignore Branches (base branches): exclude PRs merging into matching branches. Example: ^(production|staging)$ excludes PRs targeting production or staging. Useful for deployment or hotfix PRs outside regular feature work.

  • Ignore Branches (topic branches): exclude PRs that come from matching branches. Example: ^release-.* excludes PRs from branches starting with "release-".

  • Ignore Git Usernames: a comma-separated, case-insensitive list of VCS accounts. Their commits, PRs, and reviews drop out of every metric. Example: dependabot, renovate, mybot.

  • Ignore PR Comments: up to 50 case-insensitive phrases. Comments containing them drop out of code review metrics, including Comments Authored, Comments Received, and Code Review Depth. Examples: lgtm, looks good, @deploybot deploy.

PR size

  • PR Lines of Code Metrics: Ignore Files: files to leave out of PR size, in gitignore syntax. Examples: *.lock, dist/, node_modules/, *.min.js. Span also ignores a built-in list of common generated files and lockfiles; hover over the info tooltip on the settings page to see it.

Tests

  • % PRs With Tests Metric: patterns, in gitignore syntax, that define a test file. A PR counts as including tests if it changes at least one matching file. Examples: **/*.test.ts, tests/, __tests__/, spec/.

  • Ignore Repositories for PRs-With-Tests Metric: a regular expression for repositories to leave out of this one metric, even if they count everywhere else. Example: ^ci-.*. Use it for infrastructure or tooling repos where test tracking doesn't apply.

Metric toggles

  • Lines of Code Metric: turns the Lines of Code metric on or off across reports. Default: off. It's a supplementary signal alongside other size-based metrics.

  • Weighted PRs Metric: turns on the Weighted PRs metric, which accounts for PR size and complexity instead of counting every PR the same. Default: on.

  • Est Bug PR Density: turns the estimated bug PR density metric on or off.

Time-based settings

  • Cycle & Response Times: Weekends: the switch reads "Include weekends in PR cycle time, issue cycle time and review response time." Default: weekends excluded. When excluded, Span removes whole Saturdays and Sundays in your organization's time zone. When included, all calendar time counts. Activity counts such as commits and PRs aren't affected.

  • Meeting Time: the smallest gap between meetings that still counts as focus time. Shorter gaps count as fragmented time. Focus Time = 8-hour workday − meeting time − fragmented time.

Option

Effect

30 min

Only very short gaps are fragmented; more time counts as focus.

60 min

Moderate threshold.

90 min (recommended)

Default; balances sensitivity and accuracy.

120 min

More gaps are fragmented; less time counts as focus.

Incidents (CFR & MTTR)

Requires an active Jira integration. If you don't see this card, ask your Span account team. Define which Jira issues count as incidents for Change Failure Rate and Mean Time To Recover. The rule builder combines conditions with AND/OR and can match on issue type, priority, label, project, epic, initiative, and custom fields. Example: Issue Type = Incident AND Priority = Critical. Span uses the definition for Total Incidents, Incident Frequency, Change Failure Rate (the share of deployments that cause an incident), and Mean Time To Recover (average time to resolve an incident). Align it with how your team classifies production incidents in Jira.

Issue Lifecycle Report

Break the To Do and In Progress stages into substages for more detailed tracking. Click Configure Substages to set them up.

Setup

  1. Go to Settings → Metrics. You need the Metrics Configuration permission. Owners and Admins have it by default, and an Owner can add it to any custom permission group.

  2. Change a setting and save that card.

  3. Wait for the next metrics sync before checking reports.

Things to know

  • Changes aren't instant. Settings save right away, but metrics reflect them after the next scheduled sync.

  • Weekend exclusion drops whole days. Worked example: a PR opened Friday at 5 PM and merged Monday at 9 AM spans 64 hours. With weekends excluded, Span removes all of Saturday and Sunday (48 hours) and counts 16 hours. With weekends included, it counts 64.

  • Weekends follow your time zone. Span decides where a weekend starts and ends from your organization's time zone, set in Settings → Org Calendar.

  • No working-hours setting. Span uses the same 8-hour workday for everyone, based on your organization's time zone, regardless of where each person works. Weekend exclusion is the only time-of-week control.

  • Org Calendar also changes numbers. It sets your time zone, fiscal year start, and out-of-office source.

Related articles

Need help?

Contact your Span account team or reach out to support@span.app.