Most engineering teams that use Atlassian tools—Jira for project tracking, Confluence for documentation, Bitbucket or GitHub for code—want to track DORA metrics. The four metrics identified by Google's DevOps Research and Assessment team are the best validated way to benchmark software delivery performance.
The question is: what does Jira cover natively, where does it fall short, and how do you get the complete picture?
What Jira Covers Natively
Cycle Time and Throughput
Jira Software's board insights show cycle time (time from In Progress to Done) and throughput (issues completed per period). These are useful delivery metrics but they're not DORA metrics.
Jira cycle time ≈ DORA Lead Time for Changes, but only approximately. Jira measures issue lifecycle. DORA Lead Time measures from first code commit to production deployment. They diverge whenever:
- Developers start coding before moving a ticket to In Progress
- A PR sits in review without a corresponding Jira status change
- Deployment happens separately from the ticket being marked Done
Incident Tracking
Jira is widely used for incident management. If your team logs incidents as Jira tickets—with an Incident or Bug issue type and defined priorities—you have the raw data needed to calculate MTTR.
The gap: Jira doesn't automatically calculate MTTR from those tickets. You need to query issue data or export it to get aggregate numbers.
What Jira Doesn't Track
Jira has no visibility into your deployment pipeline. It doesn't know:
- When code was deployed to production
- Which commits or PRs went out in each deployment
- Whether a deployment caused an incident (Change Failure Rate)
- How many times you deployed last week vs. this week (Deployment Frequency)
Without deployment data, two of the four DORA metrics—Deployment Frequency and Change Failure Rate—are impossible to calculate accurately from Jira alone.
Mapping DORA Metrics to Atlassian Tools
Deployment Frequency
What you need: A reliable deployment signal—when does code go to production?
Jira's role: None directly. Jira doesn't have a deployment concept unless you've configured Jira Software deployments (which requires connecting your CI/CD pipeline).
How to get it: Connect your deployment pipeline (GitHub Actions, CircleCI, Jenkins) to track deploys. If you're using GitHub, GitHub Releases and the Deployments API provide a clean signal.
Lead Time for Changes
What you need: Time from code committed → production deployment.
Jira's role: Partial. If you link PRs to Jira tickets, you can approximate when work started. But "ticket moved to Done" ≠ "deployed to production."
How to get it: Measure from PR open date (or first commit) to deployment timestamp. This requires correlating GitHub PR data with deployment events—which Jira alone can't do.
Change Failure Rate
What you need: Which deployments caused production incidents?
Jira's role: Jira tracks incidents. But connecting a Jira incident ticket to a specific GitHub deployment requires correlation by timestamp and service—logic that doesn't exist natively in Jira.
How to get it: Tools that integrate both GitHub deployments and Jira incidents can correlate them: if an incident ticket was created within N hours of a deployment to the same service, that deployment is marked as a failure.
MTTR
What you need: Time from incident detection to service restoration.
Jira's role: This is where Jira contributes most. Incident tickets have Created (detection) and Resolved (restoration) timestamps. MTTR = average of (Resolved − Created) across incident tickets.
The gap: Jira doesn't surface this as a metric automatically. You need to query it, export it, or connect a tool that calculates it for you.
How to get it: Configure Jira issue types to identify incidents (by issue type, priority level, or label). Then automate the calculation. See our full MTTR guide for what to track beyond just the aggregate number.
Atlassian + GitHub: The Common Setup
Most teams using Atlassian also use GitHub (or Bitbucket). The typical setup:
- Jira: Stories, bugs, incidents
- GitHub: Code, PRs, deployments
- CI/CD: GitHub Actions, CircleCI, or similar
DORA metrics require data from all three. Neither Jira nor GitHub alone gives you the full picture.
Velocinator integrates with both GitHub and Jira to automatically calculate all four DORA metrics:
- Deployment Frequency from GitHub Releases and the Deployments API
- Lead Time from PR open to deployment
- Change Failure Rate by correlating GitHub deployments with Jira incident tickets
- MTTR from Jira incident ticket timestamps, enriched with GitHub hotfix PR data
You configure which Jira issue types count as incidents and which priority levels matter. Velocinator handles the rest.
Setting Up DORA Metrics Tracking in Your Atlassian Environment
Step 1: Define incidents in Jira
Create a consistent way to identify production incidents in Jira. Options:
- A dedicated "Incident" issue type
- Bugs with priority P0 or P1
- A specific label like
production-incident
Consistency matters more than which approach you choose.
Step 2: Link Jira to your deployment pipeline
If you're using Jira Software, you can connect your CI/CD tool to show deployment status on tickets. This doesn't give you DORA metrics directly but establishes the data link.
Step 3: Track deployments separately
Your most reliable deployment signal is in your CI/CD system or GitHub, not Jira. Treat deployments as a first-class event: tag releases, use the GitHub Deployments API, or emit deployment events to a tracking system.
Step 4: Automate the calculation
Manual queries and spreadsheets break down as your team grows. Connect your Jira and GitHub data to a tool that calculates DORA metrics continuously and shows trends over time.
Teams that instrument their Atlassian stack with deployment data and automate the metric calculation consistently find their DORA numbers improve—not because tracking magically helps, but because visibility drives action. For a baseline on what the metrics mean and what good looks like, the DORA metrics guide is the right starting point.
Frequently Asked Questions
- Does Jira track DORA metrics natively?
- Jira has some built-in metrics in Jira Software's board insights, including cycle time and throughput. But it doesn't natively calculate all four DORA metrics—especially Deployment Frequency and Change Failure Rate, which require connecting deployment pipeline data to issue data.
- How do I calculate MTTR in Jira?
- You can approximate MTTR by measuring time from incident ticket creation to resolution. Configure a Jira project with an Incident issue type, and track the Created → Resolved timestamps for tickets marked as incidents. Tools like Velocinator automate this and correlate it with GitHub deployment data.
- What's the difference between Jira cycle time and DORA lead time?
- Jira cycle time measures time from when work starts (ticket moved to In Progress) to completion. DORA Lead Time for Changes measures from code committed to that code running in production. They're related but not the same—DORA lead time includes pipeline and deployment time that Jira doesn't track.
