When making changes to your production services, it’s important to have a plan for how to detect problems and roll back changes. How many roll out plans would include: “if it breaks, don’t worry, the users will tell us!” But if your monitoring coverage of production services isn’t complete, you’re implicitly relying on your users to tell you when something breaks.

People keep asking us here at Checkly if and how AI can help create solid and maintainable Playwright tests. To answer all these questions, we started by looking at ChatGPT and Claude to conclude that AI tools have the potential to help with test generation but that "normal AI consumer tools" aren't code-focused enough. High-quality results require too complex prompts to be a maintainable solution.

We all implement tools to monitor our nodes and keep our entire cluster up and running. But how often do updates, failures, or errors mean that users suffer outages, even though our status boards look green? As Kubernetes has enabled more complex microservice architecture, the gap between the state of the dashboard, and the health of services for the user, has grown wider.

I'm a bit of an AI skeptic. And even though GitHub Copilot is my daily auto-completion on steroids, I always double-check the code generated by LLMs. If you're using AI for coding, you probably know that the results are sometimes surprisingly good and other times shockingly terrible. Lately, I have seen more and more articles and even docs recommending ChatGPT to generate Playwright tests. Could this be true? Are ChatGPT and friends really that good at generating test code?

Thanks to Microsoft's Playwright, running end-to-end tests with real browsers is quickly done. Initialize a new Playwright project, install all the dependencies, and off you go! Then, any new headless browser test run is only one npx playwright test away. But have you checked all the test command's CLI options? playwright test includes a few real gems to help you create better tests faster. Let me share a mixed bag of my favorite CLI tricks in this post.

In a previously released YouTube video, I explained how and why Playwright fixtures perfectly match with page object models. Combining the two allows you to hide setup instructions and keep your tests clean. Page object models no longer have to be initialized in every test case. To be upfront — I'm a fixture fanboy! But what if you need to pass additional configuration to your page object models? When options are hidden in a fixture, you can't configure how a class is initialized, right? Wrong!

Today I want to show you how you can attach your screenshots directly to Playwright's test reports. Imagine you have a simple Playwright test that navigates to Checkly. You take a screenshot and store it in screenshots/home.png. Then, you click a link in the main navigation, expect a specific heading to be visible, and take another screenshot. When you run this test using npx playwright test, the test passes, and you find the screenshots in the /screenshots directory.

One of our Slack community members recently asked if they could use Playwright and Checkly to detect broken links on their sites. They certainly can, and the answer to this question covers so many different Playwright concepts that it makes a perfect case for sharing Playwright features with the community. Let's unveil some links going nowhere! If you prefer the video version of this tutorial,

You probably know that Microsoft’s Playwright is a solid tool for end-to-end testing, enabling you to control headless browsers and check essential user flows. But did you know that you can also use Playwright for API testing? If you didn’t, then this guide is for you. In this post, we’ll explore how Playwright can be used to test a GraphQL API (but don’t worry if you’re using REST; Playwright can handle any HTTP-based API).

You can write Playwright end-to-end testing code using JavaScript or TypeScript. Which one should you choose? When I started writing my first automated browser tests, I went with JavaScript because I couldn't be bothered with the type wrangling. I just wanted to get something off the ground quickly. YOLO, right? Today, though, there are two reasons why I last wrote a JavaScript-first Playwright test a very long time ago.