Runbook automation tools

Runbook automation
for production investigations

BitSentry helps teams build incident runbooks for log investigation, service diagnostics, and recurring production issues. The goal is not generic automation. It is faster, more repeatable incident diagnosis.

Explore BitSentry Desktop See BitSentry Cloud

For on-call engineers

Build a diagnostic runbook once, then run it during the next incident instead of rebuilding the same investigation from memory.

For shared team workflows

Give the team one reviewed way to investigate a recurring production issue instead of letting every incident start as improvisation.

A worked incident

A queue backlog alert fires. The runbook checks queue depth, worker health, recent deployments, and failed jobs. AI explains the combined evidence.

What BitSentry automates

The investigation layer, not the guesswork.

BitSentry is best when you already know the checks your senior engineer runs. It packages those checks into incident runbooks and lets AI explain the evidence instead of inventing a fresh process every time.

  • Repeatable shell and HTTP checks

    Codify the commands, requests, and prompts your team already trusts.

  • AI explanation inside the runbook

    Use AI to summarize logs, interpret command output, and explain what the evidence suggests.

  • Evidence capture and handoff

    Keep the command output, AI interpretation, and conclusion together for post-mortems and teammate handoff.

Proof, not promises

What a runbook actually looks like.

queue-backlog-triage.yaml

Illustrative 
name: queue-backlog-triage
steps:
  - shell: rabbitmqctl list_queues name messages
  - http: GET https://internal/health/workers
  - data_source: sentry.issues(service="worker-pool", last="30m")
  - llm: Read the queue depths, worker health, and recent errors.
         Explain the likely cause and the safest next step.
evidence: captured per step, stored with the run

Run #142 · evidence record

✓ shell · orders queue at 14,382 messages, growing

✓ http · 7 of 8 workers healthy, worker-3 unresponsive

✓ data_source · 214 OOM errors from worker-3 in the last 30m

AI · worker-3 is OOM-looping and holding its batch. Likely cause: the 09:12 deploy raised batch size. Safest next step: restart worker-3 and revert the batch setting.

Shell commands, HTTP requests, data-source queries, and AI interpretation chain together, and every step's output is captured as evidence.

How a runbook is created

  1. Solve the incident once, the way your senior engineer already does.
  2. Capture those checks as runbook steps: shell, HTTP, data-source query, AI interpretation.
  3. Review it as a team. Commands are authorized here, at authoring time.
  4. Save it to the shared library. It is versioned, so improvements reach everyone.

How alerts connect to runbooks

In BitSentry Cloud, alerts land as telemetry and a background diagnosis starts automatically. When the pattern matches something your team has solved, the agent pulls in the runbook you wrote for it, and anyone can run it with one click from the alert. The operator always decides what action to take.

Choose the deployment

Start local or run it across the team.

BitSentry Desktop

Desktop runbook automation

Best for on-call engineers who want a local-first incident investigation tool that runs on their Mac and keeps the evidence on their machine.

Explore BitSentry Desktop

BitSentry Cloud

Shared runbooks and background investigations

Best for ops teams that want incident response automation for known patterns, shared runbooks, and an audit trail across the rotation.

See BitSentry Cloud

FAQ

Common questions.

Can the AI run commands I didn't approve?+

No. Runbooks define the boundary. The AI interprets output and picks which reviewed runbook fits; it does not invent commands.

Is this zero trust for AI agents?+

In the practical sense, yes. The agent is never trusted with open-ended access: it executes through runbooks your team approved, and every action is recorded against the run. Read our zero trust operating model for AI agents for the full picture.

What if the incident is new?+

Investigate it hands-on in BitSentry Desktop, then save what worked as the runbook. The second occurrence is where the payoff starts.

Which AI provider does it use?+

Yours. OpenAI, Anthropic, Gemini, Groq, OpenRouter, or a local Ollama model. Your key, no model markup.

What is captured for the audit trail?+

Every command, its output, and every AI response, attached to the run and queryable later.

Where do credentials live?+

As runbook secrets and global variables, configured once by an engineer. On Desktop they never leave your machine.

Do runbooks work with the monitoring I already have?+

Yes. Sentry, Wazuh, and PostHog are live today as data sources, and runbook steps can call any CLI or HTTP API.

Bring us one recurring incident

We will help you turn it into a reusable runbook and measure how much faster your team reaches root cause.

Book a pilot