Operations | Monitoring | ITSM | DevOps | Cloud

When you monitor a website at Oh Dear, the monitoring also includes the historical performance insights that belong to that monitor. It gives you a historical overview of the speed of that monitor, allowing you to see anomalies and changes over time. As of today, there's a second view available, one that matches the webbrowser visualisation of the timing of a single request. This view shows the same waterfall information you'd find in Chrome or Firefox, providing a familiar view to developers worldwide.

Would you know if your checkout form stopped working overnight? Or if a recent deploy broke your login flow? Traditional monitoring can't catch these issues - it only tells you if your site is up, not if it actually works. AI monitoring lets you describe what should work in plain English, and we'll test it like a real user would - clicking buttons, filling forms, checking content. No scripts to maintain, no complex setup.

This is part 2 of a 3-part series on SQL performance improvements. A few weeks ago, we massively improved the performance of the dashboard & website by optimizing some of our SQL queries. In this post, we'll dive deeper into the optimisations of queries with indexes.

We're obviously a little biased, but we believe we have one of the best website monitoring tools on the market today, leading in features compared to our competitors. We've already tried a variety of marketing techniques to promote our service, but none really had the impact we were looking for. Maybe we're better at actually building good software than we are at marketing it? Or are we trying what everyone else is also doing, thus making it all harder?

We have launched Request Mirror, a little free service to reflect HTTP requests. We've also open-sourced it: you can read the code in the ohdearapp/request-mirror.ohdear.app repo on GitHub. In this blog post I'd like to explain why we built it and how you can use it.

A few weeks ago, we massively improved the performance of the dashboard & website by optimizing some of our SQL queries. In this post, we'll share how we identified the queries that needed work. In the next post, we'll explore how we fixed each of them. We'll cover the basics and gradually work our way up to the more advanced/complex ways of identifying slow queries. In this post, you'll see: Let's go!

Today, we have launched our MCP server. MCP (Model Context Protocol) is a standardized way for AI models to connect with external data sources and tools. If you use a tool like Claude Code, then this is how you can connect Oh Dear to it (you can create an API token in your account settings)

The past month we dedicated time and resources into optimising the speed and experience of our public website, our dashboard and our behind-the-scenes uptime checks that we perform. Overall, our website and dashboard feels about 2x to 3x faster. The biggest gains are for our users that have > 100 sites on their dashboard, they'll get a noticeably faster loading time. For those biggest users, the dashboard is quite litterally 10x faster.

As part of our big deploy that added ping and TCP monitoring, we’ve also shipped a small, but often requested feature: you can now choose the frequency of the check we run. By default, we check your website for uptime every minute. The Lighthouse check runs daily. Using our new feature, you can now, for instance, choose that the uptime check should run every 2 minutes, and the Lighthouse check every 5 days. You can choose the frequency at the settings of the check.

A couple months ago, we sent out a survey to all our users asking what they like about Oh Dear, how they use it, and how we could improve our service. One of the things that was asked a lot was ping and TCP port monitoring. The past few months we worked hard to add this kind of monitoring to our service. And while building it, we touched upon other parts of our service and improved lots of little things. And I'm proud to share that we now have shipped it all! Let's go through it!