Website monitoring
Deployed websites and container apps need more than a green “deploy OK.” Website monitoring watches each container project’s resource headroom and can alert you — or restart the runtime — before a memory or disk squeeze takes the site down.
Configure it under Project Settings → Container → Monitoring (Show to expand).
What it watches
| Signal | How it works |
|---|---|
| Memory available | In-container reporter working-set memory versus this container’s limit. Alert when free headroom falls below your threshold (default 15% available). Docker OOM kills are treated the same when the reporter cannot send samples. |
| Disk available | Project disk free space versus the same style of threshold (default 15%). Requires a recent deploy so the reporter can send disk samples; until then the control stays unavailable. |
Thresholds and actions are per project — they do not bleed across the workspace.
What you can do when thresholds trip
- Send an email alert (on by default) — notify operators when resources fall below either threshold
- Restart container (off by default) — automatically restart the runtime to recover from a squeeze (with platform cooldowns so restarts are not thrashing)
Status on the Container page shows the current monitoring condition (healthy / warning / action taken) without opening the panel.
Why it matters
Public vibe sandboxes often leave “is it still up?” to you. For regulated or production websites on Diode, monitoring turns hosting into operated infrastructure: catch memory leaks and full disks early, keep the HTTPS site answering, and keep a paper trail of alerts.
Related
- Static sites and container apps
- Automation API —
project/healthandproject/logsfor scripted checks - Billing, credits, and plans