Operations | Monitoring | ITSM | DevOps | Cloud

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.

Adopting best practices for software deployment is essential to maintaining a high standard of quality, minimizing downtime, and ensuring that your applications meet user expectations. Here are five best practices to help you deploy your software more securely and reliably.

When testing and monitoring websites end to end with Playwright, choosing the right locators is crucial. Proper locators help create tests that are less flaky and more reliable. Let's explore user-first locators and how to filter locators for more robust tests.

I've been in the observability market long before it even had that name. Over the years, observability has undergone a significant transformation. As someone who has witnessed these changes firsthand, I can attest to the dynamic nature of this field. In the early days, it was largely about basic monitoring: tracking system metrics, lots of logs, and simple alerts.

When I was first learning programming, I was implementing a markov chain and explained to my mentor that it was taking me more than a week to do. I was implementing input sanitization on my interface. “Don’t do that” said my mentor, “your tool has zero users, soon it will have one user, you.

What are the two things making your end-to-end test investment a failure? Firstly, it's test flakiness. If you've invested days (if not months) in creating your test suite and it didn't turn out to be like this one trustworthy friend you have in your life for decades, you failed. You failed because eventually, you'll discover that every moment waiting for retrying tests became a burden.

Our mission at Checkly is to enable engineers to detect and resolve issues 10x faster. We are very excited to announce $20 million in Series B funding led by Balderton, alongside the participation of our existing investors Accel and CRV.