OpsKeeper
Introduction

Welcome to OpsKeeper

OpsKeeper is the auditable operations platform for multi-agent incident response. These docs walk through how to run it, how to extend it, and how the closed loop keeps mutating actions under human control.

Get started Read the architecture

What OpsKeeper is

OpsKeeper connects alert intake, evidence collection, root-cause analysis, human approval, narrowly authorized recovery, independent verification, and post-incident learning in one closed loop. Each phase is an explicit state transition with a guard. Each transition is an append-only ledger event.

Who it is for

  • SRE / DevOps teams who want agent-driven incident response with a verifiable audit trail.
  • Platform teams building an internal incident response product on top of an open source core.
  • Security teams who need mutating actions to be authorized, scoped, and replayable.

How to read these docs

If you are evaluating OpsKeeper, start with Getting started and the Architecture page. If you are operating it in production, the Operations manual is the day-2 reference. If you are extending it, head straight to Plugins.

The closed loop in one snippet

Every incident runs through the same eight phases. The control plane refuses to advance a phase until its guard is satisfied:

closed-loop phases
detected → correlated → investigated → critiqued
     → approved → recovered → verified → postmortem

Principles

  1. Diagnosis reads. Read-only tools are always available.
  2. Recovery writes. Mutating tools require a proposal.
  3. A human approves. Approval is bound to a specific resource and payload hash.
  4. An independent worker verifies. The actor is not the judge.
  5. Every transition is durable. loop_event_log is append-only at the DB layer; mutating proposals are chained with SHA256.

Next

Continue with Getting started to run the closed loop locally, or jump to Architecture for the data plane.