Ensuring your web application is accessible is not just about compliance; it's about inclusivity. Tools like Google Chrome's Lighthouse provide a starting point for accessibility checks. but integrating these checks into your development workflow can significantly enhance the quality of your product. This post explores how to perform automated accessibility checks using Playwright and Checkly, leveraging the power of the axe-core library.

Welcome to the Tech Garden, a place where our monitoring tools, like to diverse flora, contribute to a thriving digital ecosystem. Our journey starts with the foundational roots of Application Performance Monitoring (APM), crucial for initial growth and stability, like the roots beneath our fruit trees.

When we talk about keeping services running smoothly, we often hear about SLAs, SLOs, and SLIs. But what do these terms mean, and how are they different? SLAs, or Service Level Agreements, are like promises between a service provider and a customer. They outline what the customer can expect in terms of service quality.

It was only as I started to study information theory that I truly understood how nonsensically the computer worked in Star Trek: The Next Generation. Decades before voice assistants and at a time when only the most basic language parsing existed in practice, the computer on Star Trek could always give you the answer you wanted. No one ever spent any time clicking into multiple windows to find an answer, and the display always gave information that could be easily summarized in words.

Look, we've all been there: there's a term, you've heard it one hundred times. You've nodded as others said it in meetings. And now, you've started to say it. The only tiny insignificant problem is that you're not 100% sure what it actually means or how it's different from another similar term. I feel you. So I wrote this DevOps glossary with my highly opinionated definitions of common DevOps industry terms.

Every time I share a project using SaaS tools, someone inevitably responds that they could do the same thing on their own home server ‘for free.’ I mention this not because it is annoying, since I would never go on social media at all if annoying responses were allowed to change my behavior, but because I think it points to a basic misconception that still affects DevOps practitioners today: the refusal to accurately estimate the real costs of self-managed solutions.

How often should you ping your site? Should you be checking every few minutes, or every hour? Surely you have other ways to detect problems, so maybe just a daily check of your API and main page would be enough, right? While there’s no single right answer for everyone, this post tries to break down how you can find the right cadence for your site checks.

Let’s face it. Incidents will always happen. We simply can’t prevent them. But we can strive to mitigate the impact incidents have on our product and customers. Ensuring high reliability depends on quickly and effectively finding and fixing problems. This is where the metric MTTR, standing for “mean time to restore” or “mean time to resolve,” becomes valuable for organizations.

The roles of testing and monitoring often intersect, yet they maintain distinct identities. In my near-decade in the tech sector I've observed how end-to-end (E2E) tests and synthetic monitoring, despite common frameworks and requirements, often fail to benefit from collaboration and synergy.

I am happy to announce that Checkly now supports parallel scheduling as a new way to schedule your checks. Parallel scheduling allows you to reduce mean time to detection, provide better insights when addressing outages, and give improved accuracy in performance trends, making it a powerful new feature for all Checkly users.