How to Set Up Deployment Frequency Tracking: A Step-by-Step Guide for Engineering Teams

Deployment frequency is one of the four DORA metrics, and arguably the most telling signal of how well your engineering team is actually shipping. For startup dev teams, it answers a deceptively simple question: how often are you getting working software into production? The answer reveals quite a lot.

Teams that deploy frequently tend to ship smaller, safer changes. They catch bugs earlier, reduce rollback risk, and build a culture of continuous improvement. Teams that deploy rarely often accumulate risk with every release, and when something goes wrong, it becomes much harder to isolate the cause. The research backs this up: in "Accelerate" by Forsgren, Humble, and Kim (IT Revolution Press, 2018), elite-performing engineering teams consistently deploy on-demand or multiple times per day, while low performers may go weeks or months between releases.

But here's the problem most engineering managers run into: deployment frequency is easy to talk about and surprisingly hard to track consistently. You might have data scattered across GitHub, your CI/CD pipeline, and your project management tool. You might be eyeballing it in standups or relying on someone to manually compile a report each sprint. Neither approach gives you the ongoing visibility you need to actually improve.

This guide walks you through a practical, step-by-step process for setting up deployment frequency tracking that actually sticks. You'll go from defining what counts as a deployment, to connecting your data sources, to turning raw numbers into decisions that move the needle. Whether you're starting from scratch or trying to bring structure to a messy existing setup, you'll finish with a working tracking system and a clear picture of where your team stands.

Let's get into it.

Step 1: Define What "Deployment" Actually Means for Your Team

Before you touch a single tool or pull a single report, you need a shared definition. This sounds obvious, but it's where most tracking efforts quietly fall apart. Ask five engineers what counts as a deployment and you'll often get five different answers.

The first question to settle: what event triggers a deployment in your system? Is it a merge to the main branch? A successful CI/CD pipeline run? A confirmed production release? These are not the same thing, and conflating them will inflate or distort your numbers in ways that make the metric meaningless.

The second question: which environments count? Staging, canary, and production deployments should be tracked separately. If you're counting every staging push as a deployment, your frequency numbers will look impressive while telling you nothing useful about production delivery. Most teams find it most valuable to focus on production deployments as the primary metric, with environment breakdowns available for deeper analysis.

The third question: what's your unit of measurement? If you're running a monolith, this is straightforward. If you're operating microservices, you'll need to decide whether you're tracking per service, per repository, or across the entire product. For early-stage startups, a per-service view often surfaces bottlenecks that a rolled-up number would hide.

Finally, decide how you'll handle edge cases: failed deployments, rollbacks, and hotfixes. Do failed deployments count toward your frequency total? They probably shouldn't inflate your "successful deployment" metric, but they absolutely should be captured separately. Rollbacks are worth tracking because a high rollback rate alongside high deployment frequency is a warning sign, not a success story.

Write this definition down. Literally document it in a shared place your engineering leads and management can reference. Alignment here isn't bureaucracy; it's the foundation that makes every subsequent step reliable. A number everyone interprets differently is not a metric. It's a source of confusion.

Step 2: Audit Your Existing Data Sources

Now that you know what you're measuring, you need to figure out where that data actually lives. This step is less glamorous than building dashboards, but skipping it is how you end up with a beautiful reporting view built on incomplete or inconsistent data.

Start by mapping every place deployment events could be recorded. Common sources include GitHub Actions or other CI/CD pipelines, deployment platforms like Vercel, Railway, or Render, container orchestration logs, and issue trackers like Linear where work is closed out after a release. You may be surprised how many places this information exists in partial form.

For each source, check what metadata is available per deployment event. The minimum you need is a timestamp, an environment identifier, and a success or failure status. More useful metadata includes the triggering commit or PR, the author, the service or repository, and the deployment duration. The richer your metadata, the more segmentation you can do later.

Now assess data quality honestly. Gaps in timestamps, inconsistent environment labeling, or events that weren't captured because a pipeline failed silently will all skew your baseline. Surface these issues now, before you build anything on top of them. A 90-day historical pull with 15 missing events is a very different baseline than a clean 90-day record.

Map each data source back to the deployment definition you established in Step 1. Some sources will align perfectly. Others will require filtering, for example, excluding staging events or filtering out manual pipeline re-runs that don't represent real deployments.

Also note the access requirements for each source. Some tools offer native exports or log files you can query directly. Others require API access or webhook configuration. Knowing this upfront helps you sequence the technical work in Step 4 without running into surprise blockers.

Step 3: Establish Your Baseline Before Optimizing Anything

Here's a mistake that's easy to make: you set up tracking and immediately start trying to improve the number before you understand what the number actually is. Optimization without a baseline is just guessing with extra steps.

Pull historical deployment data for the past 90 days. Three months gives you enough data to see patterns without being so far back that the data reflects a team or codebase that no longer exists. This is your starting point, not your goal.

Calculate a few different views of this data. Average deployments per day and per week give you your headline frequency number. Breaking it down by team or service reveals variance that averages hide. A team deploying ten times a week might look healthy until you see that eight of those deployments come from one service and two others haven't shipped in three weeks.

Look for patterns in the timing. Are there days of the week with zero deployments? Do deployments cluster heavily at the end of sprints? These patterns are often symptoms of process issues: sprint-end pressure leading to rushed releases, deployment fear causing teams to batch changes, or a Friday deployment freeze that nobody formally documented but everyone follows anyway.

Compare your baseline qualitatively against the DORA performance tiers from the Accelerate research. Elite performers deploy on-demand or multiple times per day. High performers deploy between once per day and once per week. Medium performers deploy between once per week and once per month. Low performers deploy less frequently than that. This gives you a rough sense of where you sit without treating the benchmarks as hard targets that must be hit regardless of context.

Context does matter here, especially for early-stage startups. A small team shipping a complex product may deploy less frequently than a mature team with robust test coverage and automated rollbacks, and that's not necessarily a problem. What matters is whether your frequency is improving over time and whether it aligns with the risk profile you're comfortable with.

Record this baseline formally. Write it down, put it in a document, add it to your engineering metrics tracker. A number without a reference point is just noise. You need this anchor to measure improvement meaningfully.

Step 4: Connect Your Tools and Automate Data Collection

Manual data collection is the enemy of consistent tracking. If someone has to remember to log a deployment, update a spreadsheet, or compile a report each week, the data will drift the moment that person gets busy, which is always. Automation is not optional here; it's what makes the whole system sustainable.

Start by establishing your source of truth. For most engineering teams, GitHub is the natural anchor point, since it's where code changes originate and where CI/CD pipelines are triggered. Whatever you choose, it should be a system that captures events automatically, not one that depends on human input.

Use webhooks or native integrations to capture deployment events in real time. Batch-importing logs weekly introduces lag and makes it harder to catch problems as they emerge. A webhook that fires when a deployment completes gives you a live signal you can act on. Most CI/CD platforms and deployment tools support this out of the box.

For teams building their own tracking setup, store deployment events in a structured, queryable format. At minimum, each event record should include a timestamp, environment, service or repository identifier, and outcome (success or failure). This structure makes it straightforward to run time-series queries and segment by team or service without massaging the data every time you need a report.

If you're using an engineering intelligence platform like Progress, this step becomes significantly lighter. Progress ingests data directly from GitHub and Linear, and surfaces pre-computed deployment signals based on merge volume and code churn, without requiring you to build or maintain custom data pipelines. You connect your tools, and the platform handles the analysis layer, including deployment risk assessment and change-pressure signals that go beyond a simple frequency count.

Whichever approach you take, test your integration with a real deployment before relying on it for reporting. Trigger a deployment, then verify the event appears in your tracking layer with the correct metadata. It sounds obvious, but integration issues often hide in edge cases: deployments that succeed but don't fire the webhook, pipeline re-runs that create duplicate events, or environment labels that don't match your naming convention.

One more thing to get right at this stage: capture failed deployments, not just successful ones. The ratio of successful to failed deployments is itself a useful signal. A team deploying frequently but failing often is in a different situation than a team with a high success rate, and your tracking system should be able to tell the difference.

Step 5: Build a Reporting View That Drives Decisions

Data sitting in a database helps no one. The goal of this step is to turn your collected deployment events into a view that engineering managers and team leads can actually use to make decisions, not just admire.

Start with a time-series view of deployment frequency. A bar chart or line graph showing deployments per day or per week over the past 30 to 90 days immediately reveals trends that a single number cannot: frequency climbing steadily, a sudden drop two weeks ago, a cluster of deployments that coincides with a major release push. Trends are where the insight lives.

Segment the view by team, service, or initiative. A rolled-up total is useful for executive reporting, but it hides the variation that matters operationally. When you can see that one service is shipping confidently every two days while another hasn't deployed in three weeks, you have something actionable. That's the difference between a dashboard and a decision tool.

Layer in related signals alongside deployment frequency. Deployment frequency alone tells you how often you're shipping. When you add code churn and merge volume to the same view, you get a deployment risk picture. High frequency combined with high churn and large merge volumes is a signal that you may be moving fast in a way that's accumulating technical and operational risk. Progress surfaces exactly this kind of composite signal, connecting merge volume and code churn to deployment risk in a way that a simple frequency counter cannot.

Set a review cadence and make it part of existing rituals. Engineering managers might review deployment frequency weekly as part of their operational check-in. Team leads might review it at the sprint level during retrospectives. The key is embedding the review into something that already happens rather than creating a new meeting. New meetings rarely survive contact with a busy quarter.

Finally, watch out for vanity reporting. A high deployment count that correlates with frequent rollbacks is not a success signal. A frequency number that looks great because you're counting staging deployments is not meaningful. The reporting view should make it easy to see quality alongside quantity, so the metric stays honest.

Step 6: Set Targets and Create Feedback Loops

You have a baseline. You have live data flowing into a reporting view. Now comes the part that actually changes behavior: setting targets and building the feedback loops that make improvement self-sustaining.

Set incremental targets based on where you actually are, not where you wish you were. If your team is currently deploying twice a week, targeting three to four times per week is a meaningful stretch that's achievable with focused process work. Jumping straight to "multiple times per day" from that starting point sets the team up for frustration and erodes trust in the metric itself. Progress should feel like progress.

Tie your deployment frequency targets to specific process changes. Frequency doesn't improve in a vacuum. It improves when PRs get smaller and easier to review, when review cycles shorten, when feature flags allow you to decouple deployment from release so you're not waiting for everything to be perfect before you ship. Identify the one or two process levers most likely to move your number and make those the focus, not the frequency metric itself.

Share the metric with the team transparently. Deployment frequency improves when developers understand why it matters and can see their own impact on the number. A metric that lives only in a manager's dashboard doesn't change behavior at the team level. When engineers can see that smaller PRs and faster reviews are moving the frequency number in the right direction, the feedback loop becomes self-reinforcing.

When frequency drops, investigate the cause rather than just noting the dip. A drop in deployment frequency can mean several different things: stalled PRs waiting on review, blocked work due to a dependency, deployment anxiety after a bad incident, or a team that's heads-down on a large feature that hasn't shipped yet. Each of these requires a different response. The metric surfaces the signal; your job is to diagnose what's behind it.

Revisit your targets quarterly. As the team matures, your codebase evolves, and your deployment infrastructure improves, what's achievable changes. Targets that made sense six months ago may be too conservative now, or they may need to be recalibrated as the product scales and deployments carry more operational weight.

Putting It All Together: From Tracking to Insight

Here's the six-step process in brief: define what a deployment means for your team, audit where that data lives, establish a 90-day baseline, automate data collection through integrations, build a reporting view that surfaces trends and risk, and set incremental targets backed by real process changes.

But tracking is only valuable if it changes behavior. The goal was never a better dashboard. The goal is faster, safer shipping, and deployment frequency is one of the clearest leading indicators of whether you're moving in that direction. If the metric isn't informing decisions, it's just a number someone checks occasionally and then ignores.

Deployment frequency also works best as part of a broader engineering health picture. Paired with team momentum signals (is work accelerating or stalling?), work-stream health (which initiatives are blocked?), and team morale indicators, it becomes part of a coherent view of how your engineering organization is actually operating, not just how fast it's shipping.

Before you move on, run through this checklist:

Definition documented: Your team has a shared, written definition of what counts as a deployment, including environment scope and edge case handling.

Data sources mapped: You've identified every source of deployment event data and assessed its quality and metadata coverage.

Baseline recorded: You've pulled 90 days of historical data and documented your starting frequency by team or service.

Reporting view live: You have a time-series view with segmentation and related signals like code churn and merge volume.

Targets set: You've established incremental targets tied to specific process changes, not just aspirational numbers.

Review cadence established: Deployment frequency review is embedded in an existing ritual at the right frequency for each audience.

If you'd rather skip the infrastructure-building and get straight to the insights, Progress is built for exactly this. It connects to GitHub and Linear, surfaces pre-computed deployment signals, and gives technical leaders the context they need to act, without requiring custom pipelines or manual reporting. Learn more about our services and see what deployment frequency tracking looks like when the analysis is already done for you.