App monitoring
A project's Monitoring tab, its live resource use, usage history, traffic panel with latency percentiles, visitor map, top paths and responses, plus the Health section that records container failures.
Each project has a Monitoring tab that shows how that one app is doing: what it uses right now, how that changed over time, how much traffic it gets and from where, and what went wrong with its containers.
Where this lives
Open the project and choose Monitoring in the project menu (/projects/<id>/monitoring). On a self-hosted
project it has two sections, Monitoring and Health. The same data feeds the Apps table on the
Monitoring page; clicking an app there opens this tab.
What you need first
- A deployed project. A brand-new app with no traffic shows No monitoring data yet until the first requests arrive.
- For traffic numbers, a domain served by the Synq edge. Request counts come from the edge, not from your code.
Headline numbers
A strip of four numbers for the selected period:
| Number | Meaning |
|---|---|
| Server Requests | Requests the edge served for this project. |
| Visitor-days | Distinct visitors, counted once per day. The total is an upper bound, since a returning visitor counts once per day; hover it for the busiest single day. |
| Avg Response | Mean response time. |
| Bandwidth Out | Data sent to visitors, with data received underneath. |
Domain scope
When the project has more than one domain, a picker scopes the whole tab (All domains by default, or one domain). The traffic panel, map, top paths and responses all follow it.
Resource usage
Resource usage ("Live, refreshed every few seconds") shows CPU (of the cores it may use), Memory (of its limit), Network and Disk I/O, with a Live / Disconnected marker and Reconnect if the stream drops. For a project with several services, buttons in the header switch between All services and one service; the choice also scopes Usage over time further down.
Traffic panel
On a self-hosted project the detailed traffic panel follows ("Requests the edge served for this project"). A project on Synq Cloud shows a collapsed Traffic overview chart instead.
Live, the last 60 seconds, refreshed every 5 seconds:
| Tile | Meaning |
|---|---|
| Active requests | Requests in flight right now. |
| Requests/s | Rate over the last 60 seconds. |
| Inbound / Outbound | Bandwidth per second. |
| Error rate | Share of 5xx responses: amber from 1%, red from 5%. |
| Avg response | Mean response time over the last 60 seconds. |
Over a range: choose 1h, 24h (default), 7d or 30d. A summary row shows Requests, Avg rate, Peak rate, Data in, Data out, 5xx rate and 4xx rate, followed by three charts:
- Requests per second, split by status class;
- Bandwidth, in and out;
- Response time: p50, p95 and p99. "Percentiles appear once the edge records response-time buckets." means the edge hasn't collected latency data for this window yet.
Use it to answer questions like "did the error rate go up after the last deploy?" (compare the 5xx band in
the requests chart with the deploy time) or "is the app slow for everyone or only some requests?" (a high p99
with a normal p50 means only some requests are slow).
Visitors by country
The world map shows requests by visitor country ("N requests from M countries"), with a donut and legend underneath. Countries are counted per day. Controls on the map:
- Theme / Flags: colour the countries by theme colour or by flag.
- Live: animate each incoming request on the map, from the same stream the Logs tab shows.
- Recent hits: show the list of recent requests next to the map.
If the map stays empty with "Country data unavailable on this edge", the edge can't resolve visitor countries; traffic totals are unaffected.
Top paths
Top Paths lists the most requested paths. It is the one metric that is off by default, because counting per path is about 57% of the work the edge does on every request; everything else on this tab is collected at no extra cost. Press Enable Top Paths to turn it on for this project, and Turn off Top Paths to stop. Only projects with Top Paths on contribute to the Top paths list on the Monitoring page.
Responses
Responses breaks the requests down by status code (for example 200, 304, 404, 500), with rare codes
grouped under Others.
Usage over time
At the bottom, Usage over time charts CPU and memory from samples taken every 5 minutes. The first points appear a few minutes after the app starts running, and samples are kept for 30 days.
Volume disk usage ("Measured hourly") charts the size of the project's volumes, when it has any.
Health
The Health section ("Container failures recorded for this project by the health watch") lists:
- Open incidents: problems happening now, with how long they have lasted ("ongoing for 12m");
- Recent: incidents of the last days, with how long each lasted.
Each incident has a kind (Down, Crash loop, Unhealthy or Server unreachable) and, when known, the exit code, the number of restarts, out of memory for a container killed for using too much memory, and Show log excerpt with the container's last log lines.
The records come from the Container health watch job, which checks every server's Docker containers once a minute. If it's turned off, the section warns "The container health watch is off" with Turn it on in Jobs: an empty list then doesn't mean everything is healthy. The same incidents trigger the App down, App crash looping, App unhealthy and App recovered notifications (see Notifications).
Related
Logs & monitoring
See what your app is doing (its runtime logs, its incoming web requests and its traffic) and know exactly where to look when something breaks.
Server monitoring and alerts
Watch a server's CPU, memory, disk, load and network over time, set the thresholds that open an alert, and read the traffic its edge handles.