Operations | Monitoring | ITSM | DevOps | Cloud

The uptime & availability of our status pages hasn't been great these past few days. The root cause is a persistent and pretty aggressive DDoS attack targeted at our own status page, status.ohdear.app. As a result, the overload on our systems also affected all other status pages we host for clients. We're not yet at Github or Claude levels of uptime sadness, but this isn't acceptable to us. In this post, I'll share what's happening and what steps we've already taken.

AI coding assistants have made it possible for a single developer to build and ship a production application in a weekend. Claude Code, Cursor, GitHub Copilot, and similar tools can scaffold a Rails app, write the models, generate the views, wire up the API, and push to production before Monday. This is genuinely exciting. It is also genuinely dangerous if you do not have monitoring in place before you ship.

Last updated: May 2026 If your team is 2 to 20 developers and you do not have dedicated DevOps, SRE, or platform engineering, most APM tools were not built for you. They were built for the team that has you: a team with specialists who can tune dashboards, configure alerting pipelines, manage data retention policies, and explain the monitoring system to everyone else. You do not have that team. You have developers who also handle deploys, on-call, and debugging production issues between writing features.

StatusGator now includes a new Outage Reports tab on the service monitor detail page, giving users more visibility into recent service disruptions directly where they monitor services. Users can now quickly review recent outage activity for a specific monitored service without leaving the detail page.

Cloud infrastructure has never been more reliable in theory. In practice, the last six years of cloud outage history have delivered some of the most disruptive incidents on record. Not because cloud providers got worse, but because the systems built on top of them got larger, more interconnected, and more brittle in ways that don't show up until everything breaks at once.

Catching a cascading failure in the first 90 seconds is one of the better feelings in production engineering, and it almost always comes back to your log monitoring pipeline doing its job upstream of the alert. The teams that land there consistently treat log monitoring as a real-time detection layer in its own right, and the choices you make in that pipeline shape how every incident plays out for years.

Most monitoring setups have the same weak spot. Detection is easy. Decision-making is not. StatusCake is good at telling you that something might be wrong. What happens next is where things sometimes get messy. One alert goes straight to a chat room. Another wakes the wrong person. A third ends up getting missed because the site had a brief wobble and recovered before anyone looked. Hermes is useful in that gap.

A lot of what's useful in a high-volume log source is a count, a rate, or a measurement — 5xx responses per minute, p95 request duration, job retry rate. You don't need every line to track those. You need the metric. Log-based metrics is now in beta as part of AppSignal Labs.

The fastest incident response teams treat coordination as a craft. Someone owns the call, drives the decisions, and keeps everyone moving in the same direction while the team puts the system back together. That person is the incident commander (IC), and getting the role right is what separates your 15-minute fix from a four-hour war room where nobody’s sure who’s making the call.

A well-instrumented service tells your on-call engineer which deploy broke checkout, which span ate the latency budget, and which line to revert before the support queue fills up. Getting there depends on how cleanly your application performance monitoring layer turns telemetry into answers. The sections ahead walk through how APM works, the metrics and components worth tracking, the cloud-native challenges at scale, and how to evaluate APM tooling against your real workload.