A team has GitHub Actions running on every push. Pipelines go green, tests pass, and production deploys go out when someone clicks the button in the Actions tab. In a planning meeting someone asks whether the team is doing CI/CD. Most people say yes. The honest answer is: maybe.
Having a pipeline is not the same as doing CI/CD. The question is not whether a workflow file exists in .github/workflows. It is whether the practices the pipeline was designed to enable are actually happening. This is also the framing CI/CD monitoring is built on: the signals only matter if the practices underneath them are real.
What CI/CD means (briefly)
CI/CD (continuous integration and continuous delivery) is two practices stacked together. Continuous integration means every developer integrates their changes into a shared main branch frequently, with automated tests running on every integration. Continuous delivery means every change that passes those tests is automatically made ready for release, so production deployment becomes a routine decision rather than an event.
That is the clean textbook version. It is also where most explanations stop. The definitions describe the outcome, not the discipline, and plenty of teams meet the mechanical definition while missing the point.
Why “we have a pipeline” doesn't settle it
CI/CD is first a set of engineering practices, second a toolchain. The practices are the load-bearing half: small batches, trunk-based development, fast automated tests, production hygiene, feature flags for incomplete work, deployment pipelines anyone on the team can trigger. Tools exist to make those practices cheap enough to do on every commit. Tools without the practices produce theatre: a fast pipeline deploying a week-old feature branch is not CI, it is a build script with a schedule.
This is why “we chose GitHub Actions, so we do CI/CD” is the wrong level of answer. The provider is neutral. What determines whether a team is doing CI/CD is living above the pipeline: how often developers integrate, how small the changes are, how fast the tests run, how quickly a red build gets fixed.
Continuous integration: what integrating actually means
The integrating part of CI is easier to describe than to do. It means every developer's work converges on the same branch at least once a day, with automated tests running on every integration, and a broken build halts further work until it is fixed.
A workflow file that runs on every push is the tooling half of this. It is not the whole. A team where a typical feature branch lives for a week, pulls in conflicts, gets a twenty-commit squash at merge time, and relies on a second round of integration tests after merge is not doing CI. They are doing daily pushes on a branch while the pipeline runs tests in a parallel reality. The broken integrations are still there; they just surface later, with more code on top of them.
Strict CI implies trunk-based development. Short-lived branches (hours, not days). Small pull requests that land the same day they open. Feature flags to merge incomplete work safely behind a switch rather than hiding it on a branch. The case for this is a post of its own, but the one-line version is: every day a branch does not land is another day's worth of divergence the pipeline cannot catch until it is reintegrated.
Continuous delivery: the whole loop
Continuous delivery extends CI's short loop all the way to production. The delivery half matters because the gap between “tests passed” and “change reached users” is where most organisations hide their slowest feedback.
A healthy CD setup includes automated deployment to production-like environments (not just a half-configured staging box), database migrations that can run on every deploy without downtime, feature flags so a deploy is not the same thing as a release, canary or progressive rollouts for high-risk changes, and automated rollback when things go wrong. Each of these keeps the loop closed between writing code and seeing it work in front of real users.
Continuous deployment (deploy every green commit all the way to customers) is a subset. Continuous delivery just requires that every green commit couldgo to production in a short time, with the release decision being a human or business one rather than an engineering blocker. Most teams practising CD sit between “could deploy on demand in minutes” and “do deploy on every merge”; either side of that spectrum counts.
The pipeline is scaffolding, not the thing
The clearest tell that a team has confused tools for practices is when the CI/CD conversation becomes a conversation about the provider. “We're on CircleCI.” “We migrated from Jenkins to GitLab CI.” “We chose GitHub Actions for this team.” These are tooling decisions. They say nothing about whether changes are integrating frequently, whether tests are fast enough to run on every commit, whether main is always deployable, or whether reruns are a safety net or a ritual.
The same workflow file can power a healthy CI/CD setup or a broken one. The pipeline is scaffolding. What determines which it is holding up is the discipline of the team standing on it.
What good CI/CD looks like in numbers
The DORA research programme turned “good CI/CD” into something measurable. The five metrics, deployment frequency, change lead time, change fail rate, failed deployment recovery time, and deployment rework rate (the last added in 2024), are the numeric form of “are your feedback loops actually closing?”
- Deployment frequency is how often the full loop from commit to production executes.
- Change lead time is how long one change takes to traverse the loop end to end.
- Change fail rate is how reliably the loop produces working deployments.
- Failed deployment recovery time (colloquially, MTTR) is how fast the loop recovers when it breaks.
- Deployment rework rate is how much of the loop's output is unplanned follow-ups to production incidents.
Elite performers in the latest DORA report deploy multiple times a day, have lead times under a day, keep change fail rate below 15%, and recover within an hour. Low performers sit at the other extreme: deploys once a month or less, lead times in months, failure rates above 30%, recovery in days. Benchmarks for rework rate are still emerging; DORA introduced it in 2024 and has not yet published performance-band thresholds.
The numbers are not a scorecard. They are a thermometer for whether the practices underneath are holding up. A team that suddenly sees lead time grow should look for what has changed in the practice (longer PR reviews, growing test suites, more hand-offs), not try to tune the pipeline. For the full background see what are DORA metrics; for the practical side see how to measure DORA metrics.
Where monitoring fits
Once the practices are in place, monitoring is how a team knows the system is still healthy. It is the meta-loop: one view across every loop below it, so degradation shows up before it becomes a meeting topic. Without monitoring, the first sign that CI/CD has quietly stopped working is usually a stakeholder asking why deploys feel slow.
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, is built around this frame. It calculates DORA metrics from existing pipeline data, tracks duration and stability trends, and surfaces wait-time cost alongside compute cost so the full economic picture of the loop is visible. CICD monitoring (the same topic, just the no-slash spelling) is the same problem: keep the feedback loops observable so the practices stay honest.
The product does not fix weak practices. No tool can. What it can do is make the signals visible early enough that the humans on the team have room to act. If the practices are real, the metrics will move. If they are not, the metrics will show it.
Try it on your own pipelines
The Free tier covers pipeline monitoring for small teams. Connect a provider and every workflow run shows up in one view, with no custom configuration. DORA metrics, wait-time analytics, trend charts, and alerts are available on the Team plan and above.
CI/CD Watch is built by 3CS Technologies Ltd. It started as an internal tool for tracking pipeline health across a mixed GitHub Actions and Jenkins estate. The same engine now powers the SaaS platform.