Operations | Monitoring | ITSM | DevOps | Cloud

Today, we are introducing Spike’s new logo, a new website, and honestly, a new identity from the ground up. This is very exciting day for all of us at Spike. More companies are being built today than at any other point in history. Small teams are making big products. And no matter the size of the team, every single one of them needs reliability. Reliability should not be a second-class citizen for any company, no matter where they are in their journey.

Two weeks ago, we asked ourselves a simple question: How can we improve the reading experience of Spike’s blog? There are about two hundred articles on the blog, covering alerting, on-call, incident response, and more. Kaushik and I discussed each of these topics thoroughly before turning them into articles. But when someone landed on the blog, they couldn’t easily discover these articles. It was mostly one long scroll, and though we had some categories, they weren’t organized well.

You probably spend most of your day next to an AI now. Code reviews, debugging, writing, it all happens in Claude Code, Cursor, or a chat window. But when an incident fires, you still have to leave. Open Spike, read the payload, copy the important bits over, explain the background, and only then start fixing. That gap is gone. Spike now has an MCP server. Your AI can fetch incident payloads, dig into root causes, acknowledge and resolve incidents, and set up on-call schedules and escalation policies.

We are launching a new version of our Slack app for Spike. New architecture, a proper incident workflow you can run end to end without leaving Slack, and our first real go at bringing AI into the mix. We didn’t get here in a straight line though. This is the story of why we rebuilt our Slack app from the ground up, how we did it, and what we ran into along the way.

Today I’m really excited to share the new look of our blog. Spike has had this blog for a while. Early on, it was just me and I wrote about the decisions I was making as we built Spike. Then we slowly started growing and wrote about incidents, response, escalations, on-calls and even many guides. It’s safe to say now that we are doubling down on this space! With the new design, we have intentionally kept it minimal and put the content first.

Last Christmas, after everyone had gone quiet for the holidays, I sat down with a pen and some paper and started drawing Spike. Not the Spike we actually had, but the Spike I wanted, the one I had been carrying around in my head for a long time without ever really putting it down anywhere. A little while later I brought a few of those screens into Figma and showed them to the team over coffee one afternoon.

Reducing alert noise involves drawing a line between incidents that need an immediate response and ones that do not. Get this distinction wrong and your team is either interrupted unnecessarily or misses something critical. In this guide, we’ll help you make that distinction clear. We’ll cover what counts as noise and how to reduce it without missing what matters.

Alert fatigue doesn’t announce itself. It builds quietly over weeks and months until one day a critical incident triggers and nobody responds with the urgency it deserves. By that point, the damage is already done. This guide walks through what alert fatigue actually is, how it happens, and what you can do about it.

When you launch a new service in production, you’re working with a lot of unknowns. You don’t yet know how it behaves under real traffic or which incidents are worth waking someone up for. That makes alerting for a new service a little different from what you’re used to with an established one. The goal in the early days isn’t to get everything perfectly configured. It’s to learn enough about the service to get your alerting right.

Not every incident alert needs the same kind of response. One incident may need to wake someone up right away. Another may simply need to be picked up when the team starts work in the morning. Without a clear way to tell them apart, every incident feels equally urgent. That usually adds noise and makes incident response decisions harder than they need to be. This is where two questions help: In this guide, we’ll discuss what those questions mean and the four combinations that follow.