Workflow · Operate
Incident triage
When something breaks, start from what changed. The crew correlates the symptom with deployments, config and dependencies, and proposes a mitigation.
When to use it
Errors spike, a page goes down, a customer emails. You want the likely cause and the safest next step, with evidence.
- Specialists
- 3
- Stages
- 5
- Tier
- Plan → Act
- Duration
- Minutes
Start it with one prompt.
Paste it into Claude Code, Claude Desktop or Cursor once Kapten is connected. Replace the names with yours; Kapten asks for anything it cannot infer.
Connect your agentCheckout is returning 502s in production since about 14:10. What changed, and what is the safest way to stop the bleeding?You ask
› Checkout is returning 502s in production since about 14:10. What changed, and what is the safest way to stop the bleeding?
Stage 1 · 2 agents in parallel
LookoutObservability & incidents
Scope the symptom
Which services, since when, how many requests. Reads the error rate, latency and restarts around the window.
HelmsmanReleases
List what changed
Deployments, config changes, secret rotations and scaling events in the same window.
Stage 2
LookoutObservability & incidents
Read the evidence
Pulls the relevant log lines from the affected service and its upstreams and matches them to a change.
Stage 3
KaptenOrchestration
Likely cause and options
Proposes a cause with its evidence, and ranked mitigations: roll back, scale, or toggle config.
Gate 01 · stops for your approval
Approve the mitigation
Stage 4
HelmsmanReleases
Mitigate
Applies the mitigation you approve, then watches health until the error rate returns to baseline.
Stage 5
KaptenOrchestration
Draft the postmortem
A timeline from the first error to recovery, the cause and the follow-ups to schedule.
You get
- Likely cause with log and metric evidence
- A mitigation applied with your approval
- A postmortem draft with a timeline
Related guide
An observability starter kit for a small team
More workflows
Keep the crew busy.
Production readiness review
Four specialists review an environment in parallel and hand back one prioritised list of what to fix before you rely on it.
› Run a production readiness review on the production environment of project “atlas”. Prioritise what could lose data or take us down.
- Navigator
- Warden
- Lookout
- Purser
- Kapten
Ship your first app to production
From a repository that runs on localhost to a production environment in your own cloud account, with a domain, TLS and a rollback.
› Deploy this repo to production on my AWS account in eu-west-3. Use a managed Postgres, put the API behind api.example.com and keep it under 150 €/month.
- Navigator
- Shipwright
- Bosun
- Purser
- Warden
- Kapten
- Helmsman
A preview environment per pull request
Give each pull request a complete, isolated copy of the application with seeded data, and remove it when the branch closes.
› Set up preview environments for every pull request on github.com/acme/atlas. Seed Postgres from fixtures, cap each preview at 2 € a day and delete it on merge.
- Navigator
- Bosun
- Purser
- Kapten
- Helmsman
Build with Kapten
Start with one service.
Build from there.
Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.
Free during early access. No card required. Cloud usage billed separately.