Declare incidents
Open an incident in one place so everyone responding works from the same picture.
Operate
Incidents & Runbooks
Declare, run, and learn from every incident
Declare an incident and coordinate the response in one place, then capture what you learned so the next one goes smoother. Runbooks turn a known response into a repeatable procedure your whole team can follow. You move from improvised firefighting to a practiced, documented way of recovering.
- Every incident coordinated from one shared workspace rather than scattered across chat threads
- Known response procedures captured as runbooks any team member can follow the same way every time
- A tamper-evident record behind every incident, ready for post-incident review or a compliance inquiry
The problem
When an alert fires, your team improvises. Response steps scatter across chat threads, private notes, and individual memory, so different responders take different paths through the same outage. Afterward, what the team learned stays with whoever was on call and never reaches the next person who faces the same failure.
Without IntegraCI
- Response coordinated in chat threads with no shared record
- Each responder improvising steps from memory under pressure
- No single view of who owns what or where the incident stands
- Post-incident lessons that never reach the next engineer on call
With IntegraCI
- Every responder working from one shared incident workspace
- Known fixes encoded as runbooks the whole team follows the same way
- Status and steps tracked together as the incident plays out
- Captured timelines and lessons that feed every future response
What you get
Run the response
Coordinate steps and status as the incident plays out, keeping the team aligned.
Repeatable runbooks
Capture a known response as a procedure you can run the same way every time.
Learn afterward
Record what happened so each incident makes the next response stronger.
How it works
- 1
Declare
You open an incident and bring responders into a shared workspace.
- 2
Run runbook
A matching runbook guides the team through a known, repeatable procedure.
- 3
Review and learn
You capture the timeline and lessons to improve the next response.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Runbook procedures are defined as policy as code, encoding the expected response sequence for each incident type. The steps a team must follow are stated once and applied consistently, so the response does not depend on who happens to be on call or what they happen to remember.
Recorded, tamper-evident
Every incident declaration, status update, and completed runbook step writes once to a tamper-evident audit trail with the actor and timestamp. A post-incident review or a compliance inquiry can see exactly what happened, in order, and who acted at each point.
Works with your stack
Connect the tools you already run.
Observability connectors surface the signals that inform an incident declaration; Collaboration and ITSM connectors keep external ticket and paging systems in sync.
- Better Stack
- Datadog
- Grafana
- OpenCost
- OpenTelemetry
- Pixie
- Polar Signals
- Sentry
- Bricks Software
- Flagsmith
- Meta
- Microsoft Teams
- Novu
- PagerDuty
- PostHog
- ServiceNow
- Slack
- Telegram
- +1 more
Who it’s for
Where teams reach for it.
Coordinating a production outage response
A responder declares an incident, and the team joins a shared workspace with the relevant runbook already in place. Everyone follows the same procedure rather than coordinating piecemeal over chat.
Building a runbook library from recurring failures
After resolving a problem that has appeared before, an engineer captures the response as a runbook. The next person who hits the same issue runs the documented procedure instead of starting from scratch.
Demonstrating response discipline to auditors
Regulated teams need evidence that incidents were handled according to defined procedures. The tamper-evident audit trail records each step, actor, and timestamp without requiring a separate post-hoc log.
Questions, answered.
Does IntegraCI replace our existing incident management tool?
No. IntegraCI orchestrates and connects the tools you already run. You declare and track incidents in IntegraCI while keeping external observability and ITSM tools connected through their respective integrations.
How is a runbook different from a wiki page?
A runbook in IntegraCI is a procedure your team steps through during an active incident, with each action recorded in the audit trail. A wiki page is a static document. The distinction is that runbook execution is tracked and auditable, not just authored.
Which monitoring tools can surface incidents?
Incidents can be declared manually by any authorized responder, and observability connectors can surface signals that prompt a declaration. IntegraCI does not require a specific alerting provider.
Who can see and act on an incident?
Access is governed by database-enforced row-level security, so only authorized members of your tenant can declare incidents, run runbooks, or view the incident record. Permissions follow the role model you have already configured.
Put Incidents & Runbooks on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.