Operations | Monitoring | ITSM | DevOps | Cloud

I’m thrilled to announce that Gartner added Monitoring as Code (MaC) as an emerging practice into their Hype Cycles for Monitoring and Observability and Site Reliability Engineering. We are extremely hyped about this recognition and being listed as a vendor innovating in that space. Since we founded Checkly, our vision has been that monitoring should be set up as code and live in your repository; it must be open-source based and feel natural for developers.

One of the most effective ways to monitor a critical user flow on a website—or monitor the operation of a critical API that other applications depended on—is to adopt synthetic monitoring. Synthetic monitoring is an approach to monitoring websites and applications that simulates the actions of real users via browser automation. It mirrors the actions that a visitor may take on your website, say browsing an online shop, adding items to a shopping cart, and then checking out.

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!