Deployments / Week

Last updated: October 27, 2026

Deployments / week is Span's DORA deployment frequency: the average number of successful production deployments per calendar week in your date range.

Why it matters

Deployment frequency answers "How often do we successfully ship code to production?" It is one of the four DORA metrics. More frequent deployments usually mean smaller changes, faster feedback from customers, and changes that are easier to troubleshoot or roll back. Consistent frequency points to a stable, reliable release process.

It doesn't tell you everything:

  • Quality: read it with Change failure rate and Mean time to recover.

  • Size or impact: a config change and a major release each count as one deployment.

  • Individual contributions: deployments belong to services and teams, not people.

How it works

Deployments / week = (successful production deployments ÷ calendar days in range) × 7

Span shows the result to one decimal place. A deployment counts when:

  • Status is success. Pending and failed deployments don't count.

  • The environment is production. Span treats an environment as production when it is blank or contains "prod" or "prd", in any letter case. production, prd-us, and pre-prod all count. staging, qa, dev, and live don't.

Span counts every deployment type: deploy, rollback, and restart. Each successful production operation is a production change. Span dates each deployment by when it was triggered, and the denominator is calendar days, weekends included.

Teams. By default, Span credits a deployment to the teams that own the services it lists. When Span turns on deploy-to-PR linking for your organization, it credits the teams of the linked PRs' authors instead. A deployment with no team counts in your organization total only. A deployment linked to two teams counts once for each team and once for the organization. There is no per-person view.

Where to find it. Go to Insights → Productivity → DORA. Deployments / week is the first chart, next to the Deployments total, Lead time for changes, Change failure rate, and Mean time to recover. Until Span turns on deploy-to-PR linking for your organization, the lead time chart shows PR cycle time instead. Filter by team, service, or repository, or add the metric to a custom dashboard. To see the deployments behind the number, go to Catalog → Deployments.

Setup

Span doesn't read deployments from GitHub Actions, GitLab CI/CD, or Azure DevOps on its own. Your pipeline has to tell Span each time it ships production, in one of two ways:

  1. DORA API (recommended). After a production deploy finishes, call POST https://span.app/api/dora/v1/deployments with title, triggeredAt, status: "success", and ideally environment, completedAt, services, and git.repoUrl plus the full commit SHA in git.refName. This works from any CI system or deploy script.

  2. $deploy event. Send a $deploy event through Span's events API. Span records it as a successful deployment at the event time, with the event's environment.

Then confirm your deployments appear in Catalog → Deployments. Step-by-step pipeline examples are in the related articles below.

Things to know

  • Send status: "success". A deployment sent through the DORA API without a status is saved as pending and never counts. If you post at the start of a deploy, update it to success when it finishes.

  • Name production environments so they contain "prod" or "prd", or leave the environment out. A production environment called live or main won't count. A staging environment called pre-prod will.

  • Worked examples. 28 successful production deployments over 14 days is (28 ÷ 14) × 7 = 14.0 per week. 4 over 28 days is 1.0 per week. 2 over 60 days is about 0.2 per week.

  • Short ranges swing. In a 7-day range, one extra deployment moves the value by 1.0. Compare complete periods when you look at trends.

  • Span counts all your services together. DORA's bands describe how often a single service deploys. A team with ten services that each deploy weekly shows about 10 per week in Span.

  • Span divides by 7-day weeks. A team that ships 5 times Monday to Friday shows 5 per week. Dividing by 5 working days would give a higher number.

  • Team totals can add up to more than the organization total when a deployment maps to more than one team. Don't sum team rows to get an organization number.

  • A team filter hides deployments with no team. Send services on each deployment and give each service an owning team.

  • History starts when you start sending. Deployments from before setup don't appear unless you post them.

  • $deploy events link a repository only for GitHub. Events from other platforms arrive with no repository, so Span can't infer which PRs they shipped.

  • Zero or very low? Check Catalog → Deployments for recent deployments, their status, and their environment, and check that your date range covers them.

What's a good frequency? DORA's research ranks teams that deploy on demand, several times a day, as elite, and teams that deploy less than once a month as low. The right cadence depends on your product (consumer apps often ship more often than mobile or embedded software), your industry (regulated teams may have controlled release windows), and team size. Focus on improving your own trend, and always read frequency next to Change failure rate and Mean time to recover.

Related articles

Send deployments to Span from GitHub Actions or AWS CodePipeline

How to use the DORA API to send deployment activity to Span

Change Failure Rate Report

Lead Time to Production in Span

Mean Time To Recover (MTTR) Report

Need help?

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