Testing is still the most arduous, painful, and expensive task within a DevOps practice, regardless of framework or approach. Why? Because the current approaches to testing and development are not focused on production. Production-Driven Development (PDD), allows for rapid iteration without sacrificing stability or confidence. Following PDD, a small team or single developer can launch an application in weeks that used to take multiple teams months or a year.

Hello, SREs, DevOps engineers, and developers! We have some news! At Checkly, we understand the importance of proactive monitoring and quick incident resolution in maintaining your apps’ reliability and performance. Have you heard of ilert? ilert is the incident response platform made for DevOps teams. It helps organizations efficiently respond to, communicate and resolve incidents in real-time by offering advanced alerting, on-call management, and status pages.

As you know, having reliable checks is a cornerstone of synthetic monitoring. We don’t want false alarms, or worse, checks succeeding when things aren’t working. But sometimes, problems can be hard to identify because they only happen intermittently, or in certain situations. Similarly, monitoring results can be skewed by infrastructure issues, or network errors on the monitoring provider end, causing false alarms when there is actually no problem with the product.

At our recent company retreat, we set out to achieve 2 main goals with our fully remote team: Based on the feedback from the team, we succeeded! 🎉 The retreat schedule is a key component to achieve our retreat goals, and we’re happy to share with you what works best for us!

A web application or an API breaking is a matter of when, not if. Whether the cause is buggy code making it to production or infrastructure failing to support the software built upon it, incidents of varying severity are the norm rather than the exception, appearing frequently enough that the industry has coined the terms Mean Time To Detect (MTTD) and Mean Time To Recovery (MTTR).

We are thrilled to unveil our new branding and website, reflecting our commitment to providing engineers with the best monitoring as code (MaC) platform for modern software stacks. Our rebranding efforts signify a new era for Checkly and highlight our commitment to continuous innovation and dedication to enabling a MaC workflow for you and your teams.

Today the Checkly CLI is generally available. Together with its companion — the new test sessions screen (in beta) — this marks a big milestone for us at Checkly and our users. We already talked about monitoring as code and the CLI during its alpha and beta testing phases but here is a short recap. With the Checkly CLI you have the most powerful monitoring as code workflow at your fingertips.

We believe monitoring should be set up as code and live in your repository. Today, we are thrilled to announce that our Checkly CLI is now available to everyone! The CLI is our native tool enabling monitoring as code (MaC). This is a significant achievement for us, and we owe it to our users who beta-tested the CLI and gave us valuable feedback over the past few weeks.

I’ll get right to the point: Not uniting testing and monitoring is costing you expensive engineering time, sales, and customer confidence. Below you’ll find an all too familiar scenario that outlines the problems of traditional testing and monitoring approaches and what the benefits are of a united approach to testing and monitoring through monitoring as code (MaC).