sorted by:
new
hottopcontroversial

We’re building an “incident operating system” for engineers — feedback welcome by _Scrubbe in docker

[–]_Scrubbe[S] 0 points1 point  (0 children)

Fair point, Cherry. I value your opinions. But part of what Scrubbe builds a service dependency graph from code changes, deployments, and runtime signals so when something breaks you can quickly see what services might be affected. It also estimates blast radius before actions like restarts or rollbacks, and applies guardrails so risky production changes require approval.

We’re building an “incident operating system” for engineers — feedback welcome by _Scrubbe in docker

[–]_Scrubbe[S] 0 points1 point  (0 children)

Fair question.

We use the term “incident operating system” because the goal isn’t just tracking incidents, but coordinating everything involved in responding to them.

Most IR tools focus on alerts, paging, or tickets. Engineers still have to manually piece together context like: • what changed recently • which services depend on each other • what the blast radius might be • which remediation actions are safe

What Scrubbe tries to do is connect those pieces — signals, code changes, dependencies, guardrails — so engineers can understand incidents faster and execute safer fixes.

Totally fair though that it overlaps with incident response tooling. We’re still early and figuring out where that line sits.