Just Dashboard Requests, insights, and events
Understand the traffic a deployment served, read its output, investigate failures, and create traffic alerts.
Open a project's Logs page to answer what reached the live route, what the traffic window adds up to, what the containers wrote, and what happened to them. The page has Requests, Insights, Output, Builds, and Events views. It opens on Requests when a route serves the project and on Output for a worker, a game server, or a project nothing routes to. Request readings come from the managed proxy's access record, so the application does not need to print one line per HTTP request.
The readings above the views show the request rate, the failing share, p95 response time, and bytes served, each with its last hour. The address keeps the view, the moment, and the request filters, so a copied link opens on the same question.
Requests
A page view excludes common asset and prefetch requests; it is a useful traffic reading, not a unique visitor count. The request chart plots volume by status family and p95 latency, with marks for release activation, exits, and restarts. Drag across a chart to narrow the window.
Filter by status family, path, or Pages only. Turn on Live to follow new requests; following stops when you scroll and resumes at the top. Open a request to see its client, status, timing, route, and referrer, with the container's output while it was in flight and, for a failure, what the proxy said about it. Export downloads every matching request in the window as CSV, up to 50,000 requests.
Insights
Insights groups the current window by page, client, user agent, referrer, and status. Visitors counts distinct people who opened a page, with bots and scripts counted apart. A path shows its traffic, failures, and response time, and the latency ladder helps find the slow tail. Repeated probes of paths such as /.env are listed as scanners; an administrator can Block a public client address with a host firewall deny from this view. A private, loopback, or Tailscale address is not offered that action. A firewall deny may not stop traffic to ports Docker publishes for the Caddy ingress, and the view says so.
The ingress determines which readings exist. Docker Caddy records response duration; the standard host nginx combined log does not, so nginx routes cannot produce latency figures from that format. The page reports when a record is incomplete, truncated, or temporarily stale. An empty chart with an unavailable access record does not establish that nobody requested the site.
Output and builds
Output shows what the project's containers wrote, for one service or all of them, live and back through history. Builds lists recent runs beside the chosen run's build transcript, so you can read a failed build without leaving the page; the run's own page has its steps and release.
Events
Events follows Docker container and network events for the project: starts, restarts, exits with their codes, OOM kills, health changes, and related release activity. Search or filter the feed, then open a run or audit entry when the dashboard can attribute the event to an action. Docker events are buffered from the dashboard process's start; the page says when it began watching. A restart can leave older events outside that live buffer.
Traffic alerts
Add an alert from Logs or Settings → Automation. Under Watch for, choose Failing requests, Slow responses, or No traffic, set the limit and window, and choose the notification channels to Tell. The rule announces when it starts firing and when it recovers. No traffic applies to a route that was busy; a new route with no previous traffic is not considered a silent outage. A latency alert needs duration data, so a stock nginx access record cannot evaluate it. Use Send test to check delivery through the selected channels.
For a run's steps and exact failure, use the release page. For raw files, journal entries, and container output across the host, use the host Logs guide.