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. Team plans add monitoring with 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; Team plans add 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.