Open source · MIT · read-only

The loudest error is rarely the first one.

incopilot reads your logs during an incident and tells you what went wrong, in what order, and which safe checks to run next. It works on systemd, Docker, Kubernetes and plain files, with no account and no agent.

pip install git+https://github.com/AutoShiftOps/incopilot

View on GitHub See an example report

examples/checkout-incident.log Overall: critical

09:41:07Slow operations latencymedium
09:41:12Connection limit reached saturationhigh
09:41:13Timeouts latencyhigh
09:41:14HTTP 5xx responses errors · 5×high
09:41:20Rate limiting trafficmedium
09:41:31Out of memory saturationcritical
09:41:33Restart loop errorshigh
09:41:40Connection refused errorshigh

One command per source

Each collector only reads. External tools run with a fixed argument list and no shell, and anything that looks like an injected option is rejected.

Plain text, JSON lines, logfmt and kubectl prefixes are all parsed. Health-check lines are dropped unless they report an error.

# a workload, a pod, or a label selector
incopilot k8s --pod deploy/api -n prod --since 30m

# the container that just crashed
incopilot k8s -l app=api -n prod --previous

# stdout and stderr, with timestamps
incopilot docker --container my-api --since 1h

incopilot journal --unit nginx --since "30 min ago" --packs core,nginx

incopilot file --path /var/log/app.log
incopilot file --path archive.log.gz

# or pipe anything in
kubectl logs deploy/api | incopilot file --path -

# proxy, app and pod as one timeline
incopilot bundle --unit nginx --container my-api \
  --pod deploy/api -n prod

What the report gives you

Two files per run: report.md to paste into the incident channel and report.json for pipelines.

Four Golden Signals: Every finding is mapped to latency, traffic, errors or saturation, so you can see which kind of trouble you are in.
Order of first appearance: Which pattern showed up first. Earlier ones are likelier causes; later ones are often knock-on effects.
Severity you can gate on: --fail-on high exits 3, so a post-deploy check or a timer can act on the result.
Checks filled in for you: Read-only commands with your unit, container or pod already in place. Printed, never run.
Secrets masked by default: Passwords, tokens, keys, URL credentials and emails are redacted before anything is written.
Your own patterns: Add failure signatures, noise filters and redaction rules in incopilot.toml. Packs ship for nginx, PostgreSQL, Node.js, Kubernetes and the JVM.
A dashboard when you want one: The terminal shows the essentials. Add --html for a self-contained report.html to share in an incident channel or a postmortem. See an example.

AI is optional, and it only explains

Everything above works offline. Pass --ai with your own Anthropic or OpenAI-compatible key, or point it at a local Ollama model, and the report gains up to three ranked hypotheses.

The answer is labeled unverified. Nothing a model returns is ever executed.

Sent with --ai

Finding counts and severities
Order of first appearance
Up to two redacted example lines per finding
Top repeating lines, redacted

Never sent

The raw log
Lines that matched nothing
Anything at all with --no-redact
Anything at all without --ai

export ANTHROPIC_API_KEY=...
incopilot k8s --pod deploy/api -n prod --ai

# fully local, no key
incopilot file --path app.log --ai \
  --ai-provider ollama --ai-model llama3.1

What it does not do

Correlate and explain, never auto-act. That is a design rule, and a test enforces it.

It never restarts, deletes, scales or edits anything.
Detection is rule-based. It recognizes known failure signatures; it does not understand your application.
Order of appearance is a lead to check, not proof of cause.
It reads logs only: no metrics, traces or deploy history.
Redaction is pattern-based and cannot promise to catch every secret.