Operations | Monitoring | ITSM | DevOps | Cloud

Today we’re taking our partnership with Chris Oliver (founder of Hatchbox and GoRails) one step further. With AppSignal, you can already store enriched telemetry about your applications, services, and infrastructure, along with your user context, in your AppSignal context store. You can use that context store for traditional observability reporting and workflows, or connect it to your agents over MCP or the CLI. AppSignal’s context store is what our Intelligence features are built on.

There’s no scenario in which you should be required to run six monitoring tools at once. OK, I may have been a bit dramatic there, you might actually be at a scale where you need it. But for the rest of us, it’s certainly overkill. Using UptimeRobot for, “Is the site up?”, Papertrail for logs, PagerDuty so someone actually gets notified… Tons of logins, tons of invoices, tons of separate configs, and the worst thing is, they are all unaware of each other.

MCP is generating a lot of hype nowadays (but then again, almost anything that emerges in AI seems to attract hype). The anticipation around it is similar to the level of excitement that would break out if Apple were to finally introduce USB-C to iPhones. To be fair, though, some of that hype is warranted, considering the fact that MCP provides a standardized approach to connecting agents with third-party tools, which significantly simplifies this type of integration (hence the USB-C analogy).

Vibe coding made building software feel almost too accessible. You describe what you want, an AI assistant scaffolds it, and a few hours later, something is running. So, it was only a matter of time before developers started asking the obvious question: why should I pay for a monitoring tool when I can just build my own? In all fairness, the DIY instinct is a healthy one. But monitoring is one of the last corners you’d want to cut.

An incident has hit your product. I've been there: you're context-switching between hosting, CI/CD, codebase, AppSignal for monitoring, and whatever else your product depends on to minimize downtime and potential losses. You're trying to piece everything together, but it takes a lot of time, and that's something you don't have. AI agents connected to your tooling and your monitoring data via MCP free up that time for you.

Migrating your app to a new service can be scary. Render makes the deployment side easy, but a green deploy doesn’t mean everything is working. Silent failures are often the most dangerous kind. They go unnoticed until a customer calls to report a broken webhook or you realize the queue depth has been climbing since the cutover and nobody has caught it yet. The migrations that explode on deploy are not the ones you should fear. It’s those that look fine for three days.

Python is the native language of AI-assisted development. Models are really good at writing it, and a lot of people are now shipping it without ever having written much Python themselves. The whole thing is really simple. You prompt an app, Claude Code or Cursor produces a working Flask or FastAPI backend, and you’re live in a few hours. However, there’s still a big difference between “it works on my machine” and “it works in production”.

At AppSignal, we love talking to our customers to learn how they're using the product. Recently, one of them showed us something worth sharing: with a single chat prompt, his AI agent searches production logs, closes incidents, and checks whether a pull request has shipped. Automating that kind of work turned out to be a matter of building the right agent skill.

Cursor, Claude, and their fellow tools are great when they are speaking code, but once that code hits production, they are not exactly native. However, if your code is monitored by AppSignal, an MCP server can bridge that gap and allow agents to poke around the production.

That's a wrap on Launch Week 2026. In case you missed a day, or you want the short version, here is everything we shipped.