Monitoring
Monitoring shows how your deployed apps are behaving - CPU and memory usage, request metrics, and live container logs - so you can spot problems early and understand load. It complements the per-deployment logs you get during a release.
What you can see
- Resource metrics - CPU and memory per container over time, so you can see saturation and trends.
- Request metrics - traffic and response patterns over a selectable window (e.g. 5m, 1h, 24h).
- Container logs - live stdout/stderr from the running app.
Where logs live
orkestr keeps logs close to the thing that produced them:
- Runtime logs - on the Monitoring page and the project, for the running app.
- Build and deploy logs - on each deployment, including per-step output.
- Command output - on each job run, with the exit code.
- Function logs and metrics - on each function.
Notifications and alerts
orkestr surfaces notifications for events like failed deploys and high CPU or memory pressure, shown in the console's notification center. The Pro plan adds a monitoring dashboard, and Enterprise adds alerting so you hear about problems without watching the dashboard.
Reading the signals
- Memory climbing to the cap then restarts - the app likely needs a larger per-environment memory allocation (available on paid plans), or it has a leak.
- CPU pinned at the limit - the workload needs more CPU headroom, or there's a hot loop.
- 5xx right after a deploy - check the deployment's logs; it's usually a missing env var or a port mismatch.
- First request slow after idle - on free/Pro that's a cold start after auto-sleep, not an error.
FAQ
How far back do metrics go?
Pick a time window on the page (for example 5 minutes up to 24 hours) to zoom in or out.
Can I get alerted automatically?
Notifications appear in the console for key events; Enterprise adds alerting on top.
Where do I debug a crash loop?
Start with the container logs here, then the most recent deployment to see whether it failed at build or at runtime.