Logs and metrics

Openstead separates build output, application runtime output, and platform messages. Start with the deployment log when a release fails; start with runtime logs when a live application returns an error.

Read service logsCopy Anchor Link

Open Logs in the service navigation. Select a time range and use the search field to narrow the output. You can also open a deployment to see output associated with that release.

Applications should write operational logs to standard output and standard error. A framework that writes only to a file inside the container will not automatically expose that file in the service log viewer.

For Python, enable unbuffered output when needed:

PYTHONUNBUFFERED=1

For Laravel, use a logging configuration that sends relevant output to standard error rather than only storage/logs.

Search and downloadCopy Anchor Link

Search for an exception name, request identifier, queue job ID, or another stable field. Select the time range around the failure. The download control exports the currently displayed lines; it is not a promise of an unlimited full-history export.

Runtime output is collected periodically, so a new log line can take a short time to appear. Missing output can also mean the process never started, the time filter excludes it, or the application is writing to a file instead of stdout/stderr.

RetentionCopy Anchor Link

Access to longer history follows the active paid instance, not an unsaved or undeployed plan selection. Do not rely on the dashboard as the only archive for records that must be retained longer.

Inspect metricsCopy Anchor Link

The Metrics page shows observed CPU utilization, memory use, network activity, and instance counts for running containers. Metric history is retained for up to seven days. Use it to correlate a failure with a deployment or change in resource use.

• High CPU with a growing queue can indicate that the worker needs more capacity or less expensive work per job.
• Memory near the limit can indicate an undersized instance, excessive concurrency, or a memory leak.
• An unexpected instance count can indicate a restart or a scaling operation.

Network totals and resource samples are not application tracing or request-latency percentiles. Add application instrumentation when you need route-level timings or distributed traces.

Static releases have no dedicated application container, so they do not provide container CPU or memory metrics or application runtime logs. Their build logs remain available.

Keep logs useful and safeCopy Anchor Link

Include timestamps, severity, and correlation IDs. Avoid logging passwords, tokens, full payment data, or unnecessary personal information. Openstead redacts recognized deployment secrets, but encoded or transformed values can escape simple redaction.

For recovery steps, see Troubleshooting. For resource changes, see Scaling.