I'm excited to share that Gartner has included Monitoring as Code (MaC) as an emerging practice to their Hype Cycles for SREs again, the second year in a row. Since we founded Checkly, our vision has been that monitoring should sit in your repository, be codified, and scale with your software development. There is no alternative to MaC as it allows your engineering team(s) to work together, create and maintain checks, and ultimately own their monitoring.

Monitoring JavaScript log messages is how you know, at a basic level, what the browser’s JavaScript engine is doing in detail. Playwright provides an efficient way to listen for console logs and uncaught exceptions in your pages. This capability is invaluable for developers and testers aiming to catch and resolve issues early in the development cycle. This article will guide you through the process of setting up Playwright to monitor JavaScript logs and exceptions, enhancing your testing strategy.

Starting a few weeks ago, according to npmtrends.com, Playwright surpassed Cypress in npm downloads, indicating that more projects are starting with Playwright as their preferred automation framework.

Visual regression testing ensures that your web application looks as expected and that any visual changes are intentional. These tests amount to comparing two screenshots and looking for pixels that are different. With Playwright, you can achieve this with just a few lines of JavaScript. Let's walk through the process using a simple example. Once we’ve done a visual regression test start to finish in Playwright, we’ll show how you can add Checkly tools to create visual regression monitors.

OpenTelemetry (OTel) Metrics are part of the OpenTelemetry project, which provides tools, APIs, and SDKs for telemetry data collection. These metrics capture system performance data like request latency, error rates, resource usage, and throughput. OTel aims to standardize observability across languages and platforms, making it easier to use and integrate telemetry data. Metrics are one of three core signals of OpenTelemetry along with logs and traces.

What’s the point of observability? Surely if you write good code, maintain it, handle tech debt, and administer its resources correctly, it’ll run great? Why would you need to keep a close eye on services that have already been tested and are working great? In this article I want to show how continuous monitoring of your systems closely, with tools like Checkly and Coralogix, can find problems that would have been impossible to predict or pre-optimize.