You can't improve what you don't measure. This lesson teaches which metrics to track, how to build pipeline dashboards, and when to alert — turning your CI/CD from a black box into an observable system.
The DORA Metrics (Revisited as an Architect)
| Metric | What to Measure | Alert When | Target (Elite) |
|---|---|---|---|
| Deployment frequency | Deploys per day/week | Drops below baseline | Multiple per day |
| Lead time | Commit → running in prod | > 1 hour | < 1 hour |
| Change failure rate | Rollbacks / total deploys | > 10% | < 5% |
| MTTR | Incident → recovery time | > 30 min | < 1 hour |
Pipeline-Specific Metrics
| Metric | Why It Matters | Where to Get It |
|---|---|---|
| CI duration (P50, P95) | Developer experience | GitHub Actions API / workflow logs |
| CI success rate | Pipeline reliability | Failed runs / total runs |
| Queue time | Runner availability | Time between trigger and first step start |
| Cache hit rate | Optimization effectiveness | Cache action output |
| Image build time | Container pipeline speed | docker/build-push-action duration |
| ArgoCD sync duration | GitOps deploy speed | ArgoCD metrics endpoint |
| Flaky test rate | Trust in CI | Tests that pass/fail inconsistently |
Building a Pipeline Dashboard
- name: Emit metrics
if: always()
run: |
# Write to GitHub Step Summary (free, built-in)
echo "## ⏱️ Pipeline Metrics" >> $GITHUB_STEP_SUMMARY
echo "| Metric | Value |" >> $GITHUB_STEP_SUMMARY
echo "|--------|-------|" >> $GITHUB_STEP_SUMMARY
echo "| Run | #${{ github.run_number }} |" >> $GITHUB_STEP_SUMMARY
echo "| Duration | ${SECONDS}s |" >> $GITHUB_STEP_SUMMARY
echo "| Status | ${{ job.status }} |" >> $GITHUB_STEP_SUMMARY
# Push to your observability platform (Datadog, Prometheus, etc.)
curl -X POST "$METRICS_ENDPOINT" -d '{
"metric": "cicd.duration",
"value": "'$SECONDS'",
"tags": ["repo:${{ github.repository }}", "status:${{ job.status }}"]
}' 2>/dev/null || true
When to Alert
🧠 Recall Check
- Name the four DORA metrics and their elite-level targets.
- What should you alert on IMMEDIATELY vs review weekly?
- Why track "flaky test rate" as a CI metric?
Reveal answers
- Deployment frequency (multiple/day), Lead time (<1 hour), Change failure rate (<5%), MTTR (<1 hour).
- Immediate: production failure without rollback, prolonged drift, secret exposure. Weekly: trends in duration, success rate, deployment frequency — these are optimization signals, not emergencies.
- Flaky tests erode trust in CI. Developers start ignoring failures ("it's probably flaky") → real bugs slip through. A consistently green CI pipeline requires fixing or quarantining flaky tests.
Next lesson: Disaster Recovery — what to do when everything breaks.