Table of contents
I recently talked to a customer of Checkly and he shared some thoughts about Monitoring as Code. Let’s call him Karl in this article.
Karl and I talked about why Monitoring as Code (MaC) is becoming essential for teams operating at scale. As the Head of Platform Engineering at a major e-commerce company processing millions of transactions daily, his experience shows how MaC solves a lot of the messy challenges that come with traditional synthetic monitoring setups.
The Problem: No Ownership, No Visibility
With hundreds of microservices, dozens of development teams, and critical customer journeys that need constant monitoring, Karl's observability needs are complex and demanding. Before implementing MaC, his company struggled with traditional synthetic monitoring approaches that weren't scaling with their business needs. Traditional monitoring tools often rely on shared consoles and UIs where tests are created and managed. At first, that seems fine, but it creates some big problems:
- Who owns the test or monitor? If someone creates a test in a shared console, that’s great—until that person leaves the company. Teams then end up stuck with tests they don’t understand, duplicating effort or just letting things sit unused.
- Where are the tests? Often, nobody knows what tests exist, what they’re testing, or even why they exist in the first place. They’re just floating out there, costing money.
- Monitoring is disconnected: Developers spend their days in Git—writing code, reviewing pull requests, and deploying. When monitoring lives somewhere else, it doesn’t feel like part of the workflow, and it gets ignored.
Karl mentioned that at his company, this kind of setup led to huge inefficiencies:
- They were spending $500,000 a year on E2E tests that nobody looked at.
- Teams were unknowingly running six nearly identical tests, each costing $60,000 a year.
- When outages occurred, it often took hours just to figure out which team should investigate - and even then, multiple teams would be triaging at the same time.
The Fix: Monitoring as Code
Monitoring as Code brings monitoring into the same space where developers work every day: the codebase. Karl shared how this approach has been transformative in how they deliver software:
Clear Ownership
With MaC, tests are stored in Git, right next to the code they monitor. Repos have owners, reviewers, and workflows, so if something breaks or needs updating, it’s obvious who’s responsible. It also makes it easy to track costs—if a test is expensive, the team that owns it is accountable.
Easy to Find
Tests aren’t buried in some external tool. They’re right there in the codebase, often in a folder like end-to-end-tests. This makes it easy for any developer to see what’s being tested for their service without hunting around.
Part of the Developer Workflow
Developers live in GitHub (or GitLab, etc.). By bringing monitoring into Git, it becomes part of the development process—not an extra thing to think about.
Karl said it perfectly: “Why should I leave Git for this? Monitoring should be where I already work.”
Saving Big Money - $1M!!
The financial impact was immediate and substantial. Karl's team cleaned up redundant tests across teams, removed deprecated monitors that were still running, and consolidated similar tests into more efficient implementations. Their Engineering team was able to save over $1 million in annual costs by moving to a MaC driven approach.
Why it Matters
Karl’s story shows that Monitoring as Code isn’t just a feature—it’s a way to work smarter. It gives teams the tools to:
- Take ownership of their tests.
- Cut out waste and save money.
- Keep monitoring integrated into their daily workflows.
It’s not just about writing better tests—it’s about making sure monitoring drives real value for the business. Karl summed it up well:
“Monitoring as Code is about accountability, discoverability, and making monitoring work for the teams that need it most. It’s a no-brainer for modern teams.”
Conclusion
For companies at scale, Monitoring as Code isn’t just a better way to do things—it’s the only way. It keeps teams aligned, saves money, and makes monitoring feel like a natural part of building and running software. It’s a game-changer!