Read logs and events
Find application output, build failures and resource events in one environment.
Read logs for what your application printed and events for what Lepsto did to the service. Start with environment logs when you do not yet know which service failed. Use metrics and alerts to compare resource use and HTTP behavior over time.
Before you start
- Identify the product, environment and approximate time of the problem.
- For MCP, use a product-scoped token with Deployment
readaccess. - The environment log feed reaches back 24 hours. Export output elsewhere if you need longer history.
1. Choose the log
View | Where to open it | What it contains |
|---|---|---|
Environment feed | Environment → Logs | Sources merged newest first |
Service runtime | Service → Logs | Live stdout/stderr from its replicas |
Build output | The deployment under Service → Deployments | Build output, live while building and readable afterward |
Database engine | Database panel’s Logs | Engine output |
MCP provides deployment_service_logs, deployment_build_logs, deployment_managed_service_logs and deployment_cloud_sql_logs.
Prebuilt image deployments have no build logs. Static sites have build/deploy output but no runtime application logs.
2. Narrow the environment feed
Choose the last 5 minutes, 15 minutes, one hour or 24 hours. Search matches both message text and structured fields. Use source chips and error, warn, info or debug level chips to narrow the result.
Enable Live tail for new lines or turn it off to inspect history. Scroll back within the selected window. Select a line to inspect the timestamp, source, channel, level, message and parsed fields. If it includes request_id, filter to that request.
The histogram divides the window into 60 buckets. It follows the search query, but ignores level/source chip filters, so hidden levels still contribute to it.
3. Compare with events
Read Environment → Audit for the environment record. With MCP, use deployment_events_list_by_service, optionally narrowed to a deployment, or deployment_events_list_by_environment. Filter by type and time.
Event family | What to look for |
|---|---|
deployment.queued, deployment.build.*, deployment.deploying | Acceptance, build start/success/failure and rollout start |
deployment.healthcheck.*, deployment.healthy, deployment.failed, deployment.replaced | Readiness, failure and release replacement |
deployment.variable.ignored | A stored variable was discarded because its key is reserved |
deployment.release.* | Release-command start, output, success or failure |
replica.restarted, service.scaled, service.restarted, service.restart-failed | Replica and service operations |
service.sleep-enabled, service.sleep-disabled, service.sleep-enable-failed, service.slept, service.woke, service.wake_failed | Sleep configuration and transitions |
domain.verified, domain.tls.*, domain.www-tls.*, domain.routing.*, domain.removed | Domain ownership, certificates and routing |
The wildcard notation groups related event types; use an exact event type from the record when filtering. For example, deployment.build.failed marks a failed build. Events include timestamps and type-specific details. Deployment success and failure events also appear as chart markers in Metrics.
Verify it works
Reproduce a request or application action that you expect to log, then find its timestamp and source in the feed. Use its request ID if available. For a deployment failure, match the recorded reason and event time to the relevant build or runtime output before changing the service.
Understand missing or approximate data
Observation | Explanation |
|---|---|
Old release output is absent | The environment feed includes the serving release and newest release, including a crashing newest release, but excludes older replaced releases |
Managed Postgres lines do not update live | They are read from history and on refresh; environment-managed engine logs are live-tailed |
Counts are approximate | A bounded window holds only the most recent portion; histogram and chip counts are lower bounds |
Refresh returns the same lines | Results are briefly cached |
One source shows a warning | That source could not be read; other sources still return |
Identical messages appear twice | Lines from different replicas are not deduplicated |
Structured JSON uses its textual or numeric level field. Without a level, Lepsto classifies the text: error/fatal/err, warn, debug/trace, otherwise info. Live and historical lines use the same rule.