Operations | Monitoring | ITSM | DevOps | Cloud

Monitoring has come a long way. Your team has dashboards, alerts, and automation that would've looked like magic a decade ago. Most days, things just work. But underneath all that tooling, a lot of the actual work still happens manually. An alert fires, and you pull the page-load metric from one tool, the user session logs from another, the backend trace from a third, and line them up until the story makes sense. Ten minutes, maybe fifteen pass, then you are able to fix it and move on.

At about 2 a.m. Eastern on Sunday, September 6, 2026, reports that Google services were failing started trickling into Downdetector. They did not spike. They climbed. By roughly 9 a.m. the volume was running about ten times higher than normal, with users saying that Google Search, Gmail, YouTube and YouTube TV were failing to load. That is a seven hour ramp, and it is the single hardest incident shape for an on-call team to catch.

Heroku is not shutting down. On February 6, 2026, Heroku CPO Nitin T Bhat announced that the platform was moving to a sustaining engineering model: new feature development has stopped, but Heroku remains actively supported and production-ready. There is no announced EOL date or migration deadline, existing apps can keep running, credit-card customers can continue using the service, and existing Enterprise customers can renew. What changed is the roadmap, not immediate availability.

If you've looked at SquaredUp and thought "I don't need this, I'll just use Claude", I understand completely. I've thought it too. Here's what changed my mind. I use Claude constantly. I've also spent the last few months building the parts of SquaredUp that let it in: our MCP server, the object graph and correlation, a stack of plugins. So this isn't a dashboard vendor being sniffy about AI. I've watched Claude pull from several sources and produce something genuinely useful in under a minute.

Every log estate reaches a point where volume grows faster than the value inside it. The usual response is to find the biggest source and drop it. Cutting volume is the easy part. Cutting the right half takes judgment. Log filtering is only one of four options for an expensive source, and the other three matter just as much. In this blog, you will: By the end you can defend every rule you write, including the ones that keep data. A volume cut fails in two directions.

How long does a nurse stand at a workstation waiting for a record to load before the ward gives up and reaches for paper? In most hospitals nobody measures that number, and the ticket that reaches IT describes a symptom instead of a cause. Hospital IT support runs on a different clock from corporate IT. There is no quiet Sunday night and no safe window for maintenance.

I'm investigating repeated errors in my e-commerce application, and I need to get enough context in a single Honeycomb query to piece the entire picture together. Each query returns events based on the event's WHERE clauses, but I want to know several things from outside of the event that recorded an error. Things like: Those attributes are all over the trace. That's going to make a single query tough, right? Wrong!

Tech Talks went dark for a few months, and on episode 13 I finally got to ask why. Mathias Palmersheim’s answer, delivered completely straight, was that his users were unhappy with the availability and usability of their feeders and their litter box, and he wasn’t allowed back on stream until that got fixed. The users are two dogs and two cats, and they have titles. Maisie, a Shiba Inu who came to him through a rescue, is the recently promoted chief executive pawofficer.