Read the deployment story
Build output belongs to a release. Check the source commit and follow the stages that produced the current version or stopped a failed deployment.
Logs & metrics
Less searching.
More understanding.
See the build, the running process and the resources behind your application. Openstead puts logs, service events and CPU and memory usage next to the service you are working on.
Your code. Infrastructure included.
api-service / metrics
Memory usageILLUSTRATIVE DATA
09:0009:3010:00
api-service / runtime logs
INFO
GET /api/ideas 200INFO
POST /api/ideas 201INFO
request.completed_Build outputInvestigate deployment failures
Runtime logsRead application output
CPU + memoryUnderstand resource usage
LOGS & METRICS ON OPENSTEAD
Follow the evidence without losing the context.
Go from the affected service to the deployment and output that explain its behavior. Keep infrastructure signals and application messages within the same workflow.
See what the process says
Inspect standard output and standard error from the running application. Use your application’s own log messages to investigate requests and background work.
Understand the resource picture
Review CPU and memory usage against the instance size. Use the result to guide changes to code, concurrency and resource allocation.
MADE FOR YOUR STACK
Good application logs make the difference.
Write useful messages to standard output and standard error. Include context such as a route, job type or duration so an error can lead to a clear next step.
- Keep credentials, tokens and sensitive data out of log output.
- Log retention depends on the selected instance plan.
- Add your own application instrumentation where deeper tracing is needed.
Useful application outputopenstead / configuration
EXAMPLE LOG ENTRIES09:41:02 INFO request.completed
route=/api/orders
status=201 duration_ms=84
09:41:03 INFO job.completed
type=order_receipt
duration_ms=126
09:41:05 INFO health.readyThese are example application messages. Your service logs contain the output your process writes.
PUT IT TO WORK
Built for the work
your application does.
Failed deployments
Find the command or dependency that stopped a build, fix it and check the next release.
Application incidents
Start with the service’s events and runtime messages to establish what changed and what failed.
Capacity decisions
Review resource usage before changing instance size or application concurrency.
HOW IT WORKS
Find the service. Follow its signals.
Establish the release
Identify the running or failed deployment and its source commit. Review recent service events for relevant changes.
Inspect the output
Read build or runtime logs around the issue. Include request context in your own application logs to make investigation easier.
Make a measured change
Check CPU and memory use, update the application or instance configuration, and compare the resulting behavior.
What can I see in the console?
The console provides deployment output, runtime logs, service events, and CPU and memory metrics for application services. Open the relevant service to inspect its available views.
How should my application write logs?
Write useful messages to standard output and standard error. Include enough context to investigate failures and avoid printing credentials or sensitive customer information.
How long are logs retained?
Retention depends on the instance plan: current application plans include 7, 14 or 30 days. The pricing page and console show the allowance for the plan you select.
Can I also use an application monitoring tool?
Yes. You can instrument your application with a monitoring provider that supports your runtime and network configuration. Openstead’s service logs and resource metrics remain available alongside it.
MAKE YOUR NEXT MOVE
Keep the answers close to the application.
Your code. Infrastructure included.