When production breaks, how does your team figure out what actually happened?

by

I’ve been thinking a lot about what actually happens after an alert fires.

The alert itself usually isn’t the hardest part. The frustrating part is figuring out the story behind it.

What changed?
Was there a deployment?
Which users are affected?
Is the database involved?
Is another service causing the problem?
Who needs to respond?
And ultimately, what actually caused the incident?

In many teams, answering those questions means jumping between several different tools and trying to piece the timeline together manually.

I’m building a product called ForgeOps around this problem. The idea is to connect errors, deployments, performance, traces, customer impact, and incident response into one investigation workflow.

But before I launch it, I’m trying to make sure I’m solving a real problem rather than just building something that seems useful to me.

For those of you who work with production systems:

What is the most frustrating part of investigating a production incident?

And if you could have one piece of information automatically available the moment an incident started, what would it be?

2 views

Add a comment

Replies

Be the first to comment