Monitoring, alerts and logs.
Memory, CPU, response time and traffic graphs, the health-check path, the alerts we send, and 7 days of searchable logs for every service.
Every application and every service of a project has a Monitoring tab and a Logs tab. You don't need to install anything for either.
Monitoring
Choose a period — 1 h (a point every minute), 24 h (averages of 5 minutes) or 7 d (averages of 15 minutes). The graphs:
- Memory — memory in use, without the cache the system frees by itself, against the service's limit.
- CPU — the share of its cores in use; 100% means all of them are busy.
- Response time — how long the health check takes to answer, checked every minute. Failed checks in the period are counted under the graph.
- Traffic out — data the service sent to the internet; traffic between the services of a project is not counted. Below it: this month's traffic in and out.
- Instances — how many instances ran, when the service has more than one.
The Overview also shows live usage of every service of the project, with a line for the last 5 minutes.
The health-check path
We open one page of your web service every minute to measure the response time and to know whether it answers. By default it is the home page. A page that answers quickly without heavy work suits it best — for example a /health route that returns OK.
To change it: Monitoring → Change the path, or Settings → Health check. The path starts with /, has no spaces and is at most 200 characters.
Alerts
We let you know by email (and Telegram, if you have connected it), and again when things are back to normal:
| Event | When |
|---|---|
| The application or a service stopped responding | the health check fails, or a service keeps stopping |
| A scheduled job finished with an error | after the run, with its output in the log |
| High memory use | above 90% of the limit for 10 minutes |
| High processor use | above 90% of its cores for 15 minutes |
| A database disk is filling up | at 80% and 90%, and when it is full |
| Traffic | at 80% and 100% of the project's included traffic |
| A deploy did not finish | the previous version keeps running |
High memory or processor use never stops anything — it is a sign that the service could use more resources (Settings → Resources).
To send these events to your team too — Slack, Discord or a webhook — use Settings → Notifications to your team. See Deploys.
Logs
The Logs tab shows what your application prints — to standard output and standard error.
Live
Live follows new lines as they appear. Filter lines narrows them down to a word. Choose the process: Site, one of the background workers, or Schedule for scheduled commands. With several instances, each one has its own log.
History and search
Logs are kept for 7 days. Choose a period — Last 15 minutes, Last hour, Last 6 hours, Last 3 days, Last 7 days or a Custom period — and type what you are looking for in Search the logs.
- Filter by level: Errors, Warnings and errors, Info and above or Every level. The level is shown when a line states it (as most frameworks do).
- Load older lines continues further back.
- Download saves the lines of the period as a file.
When something breaks
If a deploy does not finish, or a service stops working, Explain this error reads the last lines of the log and suggests the likely cause and how to fix it for your stack. See Developer tools.
The build log of every deploy stays on the Deploys tab.