Observability
Understand what changed. See what needs attention.
Bring deployment history, application logs and service health into the same working context. Start with the environment, then follow the service that needs your attention.
Kapten MCPWith Lookout, Helmsman and KaptenSample console for the api service in production: the 5xx error rate is flat around half a percent for forty minutes, then climbs to about four percent after the deploy of api@3f2c1a. Logs show connection errors. The Lookout links the errors to that release and has planned a rollback that awaits approval.
- Signals
- Deploys, logs, metrics, topology
- Scope
- Per environment and service
- Findings
- Linked to the release
- Fixes
- Proposed as plans you approve
Inside the product
A shorter path from symptom to context.
Interface previews
Illustrative · sample data · Early access
Start with the right service
Scope the investigation to the environment and component affected. Keep unrelated workloads out of your first view.
Keep logs close to the run
Follow application output in the context of the deployment. Start with the messages produced around the change you are investigating.
Find the latest change
Read deployment history alongside the service. A release identifier gives an investigation a concrete starting point.
Read a signal in context
Use service health and the monitoring available in your setup to understand what the application is doing. Agree coverage during onboarding.
Follow the dependency
An application issue can begin in a connected component. Keep the architecture close as you move between services and data stores.
Know where the run stopped
Read build and deployment stages separately. Distinguish a build problem from an application that starts but does not become healthy.
See it in context
The service. The release. The evidence.
Keep build and deployment output associated with the run that produced it. Start an investigation with the change your team actually made.
Commerce / staging
Everything in context.
- Services
- 4
- Latest release
- a83f1c2
- Log window
- 15 min
In this environment
payments-api
Environment scoped
Service health
4 components- storefrontWeb serviceHealthy
- payments-apiApplicationHealthy
- jobs-workerBackground workerHealthy
- postgresDatabaseHealthy
Latest application output
Application started
Database connection ready
Listening on port 8080
GET /health 200
GET /api/products 200
Early accessThe demo uses sample data. Log availability, retention and monitoring coverage depend on the alpha setup agreed during onboarding.
The Lookout’s correlation
From symptom
to the change behind it.
An alert says something is wrong. The Lookout says what changed: it lines up deploys, metrics, logs and the topology on one clock, and hands back a finding with its evidence and a plan, not an action.
The incident triage workflowDeploy
api@3f2c1a released to production, 3/3 replicas healthy.
Metrics
p95 latency on POST /orders climbs from 180 ms to 1.8 s.
Database
Postgres connections reach the 100 limit.
Logs
“too many connections” on api only; web and worker are clean.
Finding
The Lookout links the errors to the release and plans a rollback.
Lookout · finding · api · production
The new release opens a database connection per request.
Evidence
- Errors start 2 min after the releaseStrong
- Only pods running api@3f2c1a are affectedStrong
- Database connections at their limitSupporting
- No infrastructure change in the windowRules out
Proposed plan · Helmsman
Roll back api to 9e1b77, the last healthy image. Then review the connection pooling change before the next release.
Awaits your approval
Illustrative · sample incident and data. The Lookout reads the signals your setup provides; coverage is agreed during onboarding.
With your crew · Kapten MCP
When something breaks, the Lookout starts from what changed.
Kapten MCP puts a crew of specialists inside the coding agent you already use. On Observability, these are the ones on watch. They read and plan freely; anything that changes your infrastructure waits for your approval.
Meet the whole crewLookoutObservability & incidentsLeads
Correlates errors with the latest release and reads the logs of the affected service.
HelmsmanReleases
Lists what changed in the window and applies the mitigation you approve.
KaptenOrchestration
Brings back a likely cause, the evidence and a draft timeline.
Try asking
Checkout has been slower since lunch. What changed in production, and what do the payments-api logs say?
- Kapten splits the request between Lookout and Helmsman.
- Lookout correlates errors with the latest release and reads the logs of the affected service.
- Helmsman lists what changed in the window and applies the mitigation you approve.
- Plan ready. Nothing changes until you approve it.
Observe & Plan · no approvalAct · your approvalIllustrative run · early access
Workflows that use it
How it works
Turn an alert into an investigation.
Each station names the crew member that owns it. Diamonds are gates: the run stops there until a person decides.
- Locate the serviceLookoutChoose the environment and component showing the problem.
- Find the recent changeHelmsmanReview the deployment and its output around the time of the issue.
- Follow the evidenceLookoutRead runtime logs and connected components to narrow the cause.
Deep dive
The ideas behind it.
Follow a deployment
Keep build and deployment output associated with the run that produced it. Start an investigation with the change your team actually made.
Read the relevant logs
Scope application logs to a component and environment. Narrow the time window around the issue instead of mixing unrelated workloads together.
Keep the topology close
Use the architecture canvas to understand a service’s place in the application. Move from the shape of the system to the component you need to inspect.
Good to know
A little more
before you start.
Have a particular application or setup in mind? Bring it to the early-access conversation.
Talk through your setupDoes this replace my existing monitoring stack?
Plan around your current incident workflow. Confirm the signals, retention and integrations you need before deciding which tools to keep or replace.
Where should I start investigating a failed release?
Select the environment and affected service, then inspect the latest deployment and its output. Check runtime logs if the build succeeded but the application is unhealthy.
Can the Lookout fix an incident on its own?
No. The Lookout reads signals and links them to a likely cause. When a fix is needed (a rollback, for example), it is proposed as a plan, and the plan waits for your approval like every other change.
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.