This article is based on a piece originally published on TechTarget’s DevOps Agenda, authored from a practitioner’s perspective on monitoring and observability in DevOps.
Monitoring Is Hot — and Rightly So
Monitoring and observability have become central conversations in modern DevOps. Practitioners like Charity Majors have done significant work articulating why systems must be designed to be interrogatable — not just functional. The goal is to build software that can tell you what it is doing under any condition, not just the happy path.
But awareness of observability’s importance hasn’t always translated into practice. Too often, operations metrics and production telemetry are still treated as something you bolt on at the end, once the code is already in production. That approach is expensive, fragile, and at odds with everything DevOps stands for.
The Case for Shifting Left — Beyond Testing
Most DevOps teams are familiar with the principle of shift-left testing: move testing activity earlier in the software development lifecycle (SDLC) so that defects are caught sooner, feedback loops are shorter, and the cost of fixing problems stays low. Parallel testing during development reduces the time between writing code and knowing whether it works correctly.
The same logic applies to security (DevSecOps) and, equally, to operations metrics and telemetry. If you have successfully compressed the feedback loop between development and testing, but your operations monitoring only activates the moment code hits production, you have left a significant gap at exactly the wrong place.
The Old Feedback Loop Was the Problem
Before Agile and DevOps became mainstream, software was delivered in large, sequential phases. Development took months. Testing took months. Reviews, approvals, and sign-offs took more months. In many organisations, it was six months to two years between writing code and deploying it to a real production environment on real infrastructure.
Under that model, production monitoring was genuinely a last step — because production itself was a last step. You had no environment to monitor until the very end of the process. That delay in feedback was one of the core problems DevOps set out to solve.
Agile and DevOps compress those phases. Work is broken into smaller increments. Delivery is continuous. The feedback loop between writing code and seeing it run in a production-like environment shrinks from months to days or hours. That faster feedback is what allows teams to deliver value to customers more reliably and more often.
The Telemetry Gap That Persists
Despite continuous integration, automated deployments, infrastructure as code, and near-complete test automation, many teams still treat operations telemetry as a final-phase activity. As Gene Kim describes in The DevOps Handbook, telemetry — the collection and transmission of operational data from running systems — is one of the three core technical practices of DevOps flow. Yet it is often the last to be implemented.
The consequences are predictable:
- Essential system behaviours are never defined as requirements, so they are never instrumented.
- Monitoring configurations are slapped together at go-live under time pressure.
- Baselines are never established early, making anomaly detection unreliable.
- Alert thresholds are guessed rather than tuned, producing noisy, meaningless alarms or dangerous false silences.
- Significant production outages or SLA violations occur before the team has enough observability to understand why.
Every experienced system administrator knows the operational cost of a poorly configured alerting system. False positives erode trust in alerts. False negatives hide real problems until they become outages. Both outcomes are avoidable when telemetry is treated as a first-class concern from the start.
Telemetry as a Non-Functional Requirement
The practical fix is straightforward: define your essential operations metrics alongside your functional requirements, not after them.
When writing a specification for a new feature or service, include:
- What the system will do (functional requirements)
- How it will perform under load (performance and scalability non-functional requirements)
- What success and failure look like operationally — latency thresholds, error rate budgets, throughput baselines, health check endpoints
- What data the system must emit — logs, metrics, traces — so that its behaviour can be verified in any environment
By encoding these decisions early, developers can instrument the application as they write functional code. Telemetry is not an add-on; it is part of the deliverable.
Build Telemetry in Tandem With Code
Whether your pipeline deploys to a staging environment first or goes straight to production via continuous deployment, your telemetry should be functional and meaningful from the first deployment — not the last.
A practical approach:
- Define metrics alongside user stories. Before a story is considered complete, agree on which metrics it should affect and what healthy values look like.
- Instrument as you code. Add logging, metrics emission, and tracing hooks in the same pull request as the feature code. Treat uninstrumented code as incomplete.
- Test telemetry in CI. Verify that the expected metrics are emitted and that alerting rules fire correctly in automated tests, not just by manual inspection in production.
- Baseline early. Use early test environment deployments to establish what normal looks like before traffic is real, so anomaly detection has something meaningful to compare against.
- Tune continuously. Revisit alert thresholds and metric definitions as you learn more about how the system behaves under real conditions.
Shift Operations Left: The Summary Argument
The core argument of DevOps is that tightly coupling development, testing, security, and operations — rather than treating them as sequential handoffs — produces better software faster. Shifting operations metrics and telemetry left is a direct extension of that principle.
When telemetry is treated as a first-class SDLC citizen:
- Teams gain operational insight from the first deployment, not the hundredth.
- Developers understand the operational impact of their changes in near real time.
- Operations teams have well-tuned, meaningful signals rather than noise.
- SLA commitments are grounded in observed baselines, not guesses.
- Incidents are detected and diagnosed faster because the instrumentation already exists.
DevOps is not a destination with a fixed finish line. But if your telemetry only starts working the day you go live, you are carrying avoidable risk and rework through every sprint before that point. Shift operations left, run it in parallel with development and testing, and the entire feedback loop becomes what it was always supposed to be: fast, reliable, and continuous.
Further reading: Charity Majors’ work on observability is widely available on her blog and through LeadDev and Strange Loop conference talks. Gene Kim’s The DevOps Handbook (co-authored with Jez Humble, Patrick Debois, and John Willis) covers the three ways of DevOps, including telemetry, in depth.