Skip to content

Measure DORA Metrics

Time to Complete: 30 minutes Goal: Understand how your service contributes to team DORA metrics and use data to drive improvements.

What You'll Learn

By the end of this tutorial, you will have:

  1. ✅ Understood the four key DORA metrics
  2. ✅ Configured your service for DORA metric collection
  3. ✅ Viewed your service's metrics in Apache DevLake dashboards
  4. ✅ Analyzed trends and identified improvement opportunities
  5. ✅ Understood how Fawkes automates DORA data collection

Prerequisites

Before you begin, ensure you have:

  • [ ] Completed Tutorial 1: Deploy Your First Service
  • [ ] Your hello-fawkes service deployed and operational
  • [ ] Access to Grafana (typically at https://grafana.127.0.0.1.nip.io)
  • [ ] Access to DevLake (typically at https://devlake.127.0.0.1.nip.io)
  • [ ] At least a few deployments of your service (from previous tutorials)

What are DORA Metrics?

DORA (DevOps Research and Assessment) identified four key metrics that predict software delivery performance: 1. Deployment Frequency - How often you deploy to production 2. Lead Time for Changes - Time from commit to production 3. Change Failure Rate - % of deployments causing failures 4. Time to Restore Service - Time to recover from failures

[Learn more about DORA capabilities](../capabilities.md).

Step 1: Understand DORA Metrics

Let's review what each metric measures and why it matters.

Deployment Frequency

Definition: How often an organization successfully releases to production.

Elite Performance: Multiple deploys per day Industry Average: Between once per week and once per month

Why it matters:

  • High frequency = smaller changes
  • Smaller changes = lower risk
  • Lower risk = faster feedback

Lead Time for Changes

Definition: Time from code committed to code successfully running in production.

Elite Performance: Less than one hour Industry Average: Between one week and one month

Why it matters:

  • Short lead time = fast feedback
  • Fast feedback = rapid iteration
  • Rapid iteration = better products

Change Failure Rate

Definition: Percentage of changes that result in a failure in production.

Elite Performance: 0-15% Industry Average: 31-45%

Why it matters:

  • Low failure rate = stable releases
  • Stable releases = customer trust
  • Customer trust = business success

Time to Restore Service

Definition: Time it takes to recover from a failure in production.

Elite Performance: Less than one hour Industry Average: Less than one day

Why it matters:

  • Fast recovery = minimized impact
  • Minimized impact = satisfied customers
  • Satisfied customers = retained revenue

Checkpoint

You understand what DORA metrics are and why they matter.

Step 2: Access DevLake Dashboard

Apache DevLake is Fawkes' data platform for DORA metrics.

  1. Navigate to DevLake in your browser:
https://devlake.127.0.0.1.nip.io

  1. Log in with your credentials (ask your platform team if you don't have them).

  2. You should see the main dashboard with:

  3. Projects list

  4. DORA metrics overview

  5. Trend graphs

  6. Navigate to Dashboards → DORA Dashboard.

  7. Use the filters to select your service:

  8. Project: my-first-app
  9. Repository: hello-fawkes
  10. Time Range: Last 30 days

No Data Yet?

If this is your first deployment, you may not see much data yet. That's okay! We'll generate more data in this tutorial.

Checkpoint

You can access the DevLake DORA dashboard and filter by your service.

Step 3: Configure Data Collection

Fawkes automatically collects most DORA data, but let's verify the configuration.

  1. Check that your ArgoCD application has DORA annotations.

View argocd-app.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: hello-fawkes
  namespace: argocd
  annotations:
    # DORA metric annotations
    dora/team: "platform-team"
    dora/service: "hello-fawkes"
    notifications.argoproj.io/subscribe.on-deployed.devlake: "webhook"
spec:
  # ... rest of spec
  1. If annotations are missing, add them:
kubectl annotate application hello-fawkes -n argocd \
  dora/team=platform-team \
  dora/service=hello-fawkes \
  notifications.argoproj.io/subscribe.on-deployed.devlake=webhook
  1. Verify ArgoCD notifications are configured:
kubectl get configmap argocd-notifications-cm -n argocd -o yaml

Should include a DevLake webhook trigger.

  1. Check that your GitHub repository is connected:
  2. In DevLake UI, go to Data Connections
  3. Verify hello-fawkes repository is listed
  4. If not, add it following the platform team's instructions

Checkpoint

Your service is configured for automatic DORA data collection.

Step 4: Generate Deployment Data

Let's create some deployments to populate the metrics.

  1. Make a small code change to server.js:
app.get("/", (req, res) => {
  res.json({
    message: "Hello from Fawkes!",
    timestamp: new Date().toISOString(),
    version: "4.0.0", // Bump version
    tracing: "enabled",
    secrets: "managed by Vault",
    dora: "tracking enabled", // New field
  });
});
  1. Commit and push:
git add server.js
git commit -m "Add DORA tracking indicator"
git push

  1. This triggers:

  2. Git webhook to DevLake (Lead Time starts)

  3. ArgoCD sync (Deployment happens)

  4. Deployment notification to DevLake (Deployment Frequency recorded)

  5. Wait for ArgoCD to sync (check in ArgoCD UI or CLI):

kubectl get application hello-fawkes -n argocd -w
  1. Make a few more changes to generate more data points:
# Change 2
git commit --allow-empty -m "Trigger deployment 2"
git push

# Wait 5 minutes

# Change 3
git commit --allow-empty -m "Trigger deployment 3"
git push

Why Multiple Deployments?

DORA metrics are trends, not single data points. The more deployments you have, the more meaningful the metrics become.

Checkpoint

You've generated deployment data for DORA analysis.

Step 5: View Deployment Frequency

Let's analyze how often you're deploying.

  1. In DevLake, navigate to DORA Dashboard → Deployment Frequency.

  2. You should see:

  3. A timeline graph showing deployments over time

  4. Total deployments in the selected period
  5. Average deployments per day/week

  6. Trend: Increasing, Stable, or Decreasing

  7. Filter by your service (hello-fawkes).

  8. Compare to team average and industry benchmarks.

  9. Example insights:

  10. "We deployed 3 times this week"
  11. "Our average is 0.6 deployments per day"
  12. "We're at 'Medium' performance tier (weekly deploys)"
  13. "Goal: Reach 'High' tier (daily deploys)"

!!! tip "Interpreting the Data" - Elite: On-demand (multiple per day) - High: Between once per day and once per week - Medium: Between once per week and once per month - Low: Less than once per month

Checkpoint

You can view and interpret your deployment frequency metrics.

Step 6: Analyze Lead Time for Changes

Now let's see how long it takes from commit to production.

  1. In DevLake, navigate to DORA Dashboard → Lead Time for Changes.

  2. The dashboard shows:

  3. Median lead time (p50)

  4. 95th percentile lead time (p95)

  5. Breakdown by stage:

    • Code commit to PR creation
    • PR creation to approval
    • PR approval to merge
    • Merge to deployment

  6. Click on a specific deployment to see its journey:

Commit: 2025-12-06 10:00:00
├─ PR Created: +5 minutes
├─ PR Approved: +10 minutes
├─ PR Merged: +2 minutes
└─ Deployed: +3 minutes

Total Lead Time: 20 minutes ✅ Elite
  1. Identify bottlenecks:
  2. If "PR approval" takes hours → Need faster reviews
  3. If "Merge to deploy" is slow → Optimize CI/CD pipeline
  4. If "Commit to PR" is long → Smaller changesets

Lead Time Stages

Fawkes tracks each stage separately so you can identify exactly where delays occur.

Checkpoint

You understand your lead time and where time is spent.

Step 7: Monitor Change Failure Rate

Let's see how often deployments cause problems.

  1. In DevLake, navigate to DORA Dashboard → Change Failure Rate.

  2. The dashboard shows:

  3. Percentage of failed deployments

  4. Failed vs. successful deployments over time

  5. Correlation with deployment frequency

  6. What counts as a "failure"?

  7. Deployment rollback

  8. Hotfix deployed within 24 hours
  9. Production incident tagged to a deployment

  10. Pod crash loops after deployment

  11. Example analysis:

  12. "3 deployments, 0 failures = 0% failure rate ✅ Elite"

  13. Or: "10 deployments, 3 failures = 30% failure rate ⚠️ Medium"

  14. If you have failures, click to see details:

  15. Which commit caused the failure?
  16. What was the error?
  17. How long until it was fixed?

!!! tip "Improving Change Failure Rate" - Increase test coverage - Add canary deployments - Implement feature flags - Improve staging environment parity

Checkpoint

You can track how often your deployments fail.

Step 8: Measure Time to Restore Service

Finally, let's look at recovery time when failures do occur.

  1. In DevLake, navigate to DORA Dashboard → Mean Time to Restore.

  2. The dashboard shows:

  3. Average time from incident detection to resolution

  4. Trend over time

  5. Incidents by severity

  6. What counts as an "incident"?

  7. Service downtime (health check failures)

  8. Error rate spike
  9. Performance degradation

  10. Manual incident creation in PagerDuty/Mattermost

  11. Example incident timeline:

Incident Detected: 2025-12-06 14:00:00 (Automated alert)
├─ Team Notified: +1 minute (Mattermost alert)
├─ Diagnosis Started: +5 minutes (Engineer joined)
├─ Fix Identified: +10 minutes (Found bad config)
├─ Rollback Initiated: +2 minutes (ArgoCD rollback)
└─ Service Restored: +3 minutes (Health checks pass)

Total MTTR: 21 minutes ✅ Elite
  1. If you don't have incidents yet (great!), you can simulate one:
# Break the service temporarily
kubectl scale deployment hello-fawkes -n my-first-app --replicas=0

# Wait 2 minutes for alert

# Restore service
kubectl scale deployment hello-fawkes -n my-first-app --replicas=2

Simulated Incidents

Only simulate incidents in development/staging. Never in production!

Checkpoint

You can measure how quickly your team recovers from incidents.

Step 9: Create a DORA Improvement Plan

Based on your metrics, create an action plan.

  1. In DevLake or Grafana, export your current DORA metrics:

  2. Deployment Frequency: X per week

  3. Lead Time: X minutes
  4. Change Failure Rate: X%

  5. MTTR: X minutes

  6. Identify your current performance tier:

  7. Elite, High, Medium, or Low for each metric

  8. Choose one metric to improve first:

  9. Pick the one farthest from Elite

  10. Or the one with the biggest business impact

  11. Set a SMART goal:

  12. Specific: Increase deployment frequency

  13. Measurable: From 3/week to 1/day
  14. Achievable: By automating tests
  15. Relevant: Faster feedback to customers

  16. Time-bound: Within 30 days

  17. Track progress:

  18. Review DORA dashboard weekly
  19. Adjust tactics based on data
  20. Celebrate improvements!

Checkpoint

You have a data-driven plan to improve your DORA metrics.

What You've Accomplished

Congratulations! You've successfully:

  • ✅ Understood the four key DORA metrics
  • ✅ Configured your service for metric collection
  • ✅ Viewed metrics in DevLake dashboards
  • ✅ Analyzed deployment frequency, lead time, failure rate, and MTTR
  • ✅ Created an improvement plan based on data

Key Insights

Through this tutorial, you've learned:

  1. DORA metrics are objective - No more arguing about "good" or "bad" deployment practices
  2. Fawkes automates collection - No manual tracking or surveys needed
  3. Trends matter more than absolutes - Focus on improving, not perfection
  4. All four metrics work together - Optimizing one at the expense of others doesn't work
  5. Elite performance is achievable - With the right platform and practices

What's Next?

Continue your Fawkes journey:

  1. Review all tutorials - Ensure you've completed 1-6
  2. Join the Dojo - Progress through belt levels for deeper learning
  3. Share your metrics - Discuss with your team and set collective goals
  4. Contribute back - Share your DORA improvement story with the community

Troubleshooting

No Data in DevLake

# Check DevLake is running
kubectl get pods -n fawkes-platform -l app=devlake

# Verify GitHub connection
# In DevLake UI: Data Connections → GitHub

# Check ArgoCD notifications
kubectl logs -n argocd -l app.kubernetes.io/name=argocd-notifications-controller

Metrics Seem Wrong

  • Verify time zone settings in DevLake
  • Check that repository is correctly tagged
  • Ensure ArgoCD sync policies are correct
  • Review incident tagging criteria

Can't See My Service

  • Confirm ArgoCD application has DORA annotations
  • Verify repository is connected in DevLake
  • Check that commits are being detected
  • Wait 5-10 minutes for data pipeline to process

Learn More

Feedback

What did you learn from your DORA metrics? What surprised you? Share your insights in the Fawkes Community Mattermost!

🎉 You've Completed All Six Tutorials

Congratulations on completing the entire Fawkes tutorial series! You now have:

  • ✅ Deployed a service to Fawkes
  • ✅ Added distributed tracing
  • ✅ Implemented Vault secret management
  • ✅ Migrated to Cloud Native Buildpacks
  • ✅ Created a Golden Path template
  • ✅ Measured and analyzed DORA metrics

Next Steps

  1. Join the Dojo - Start your White Belt journey
  2. Explore How-To Guides - Solve specific problems
  3. Read Explanations - Deepen your understanding
  4. Contribute - Help improve Fawkes

Share Your Success

  • Post your achievement in Mattermost
  • Write a blog post about your experience
  • Help others complete the tutorials
  • Contribute improvements to the docs

Thank you for learning with Fawkes! 🚀