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.
Inside the product
A shorter path from symptom to context.
Interface previews
Illustrative 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 workflow
Turn an alert into an investigation.
- 01
Locate the service
Choose the environment and component showing the problem.
- 02
Find the recent change
Review the deployment and its output around the time of the issue.
- 03
Follow the evidence
Read runtime logs and connected components to narrow the cause.
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 setup ↗Does 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.
Connected capabilities
One part of a bigger picture.
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.