Traffic & analytics shows what visitors are doing on your app: how many requests reach it, how much data it serves, how fast it responds, and how the pages feel in real browsers. Use it to confirm a launch is taking traffic, to spot a slow deploy, or to watch requests arrive while you debug.
To open it, go to your app and choose Traffic & analytics in the Traffic group of the sidebar.
Note
Preview deployments do not have a Traffic & analytics section and do not collect visitor metrics. Open the production app instead.
The summary
The page opens with one sentence about the last seven days: how many requests your app answered, about how many a day, how much data it sent, and how long responses took on average. When same-day numbers are available it adds today's count so far, and how many of those requests failed (4xx or 5xx) in amber.
Seven-day and monthly totals come from a daily collection job, so today's traffic appears the next day (usually by mid-morning UTC). Below the rows, Counted on lists the hostnames included.
Look closer
Each row under Look closer opens a dialog with the detail:
| Row | Dialog |
|---|---|
| Busiest day | Requests: this month's requests and bandwidth, and a bar for each day of requests and of bandwidth. Hover a bar for the exact value. |
| Today | Same-day requests counted at the edge (UTC day) without waiting for the daily job: requests and bandwidth today, the mix of response codes, and the top paths. |
| Response time | Average and slowest-5% (p95) response time over seven days, the share served from the edge cache, and how many requests were measured. Hybrid apps also link to Cache controls; a low cache share on static paths usually means your build sends headers that stop caching. See Caching. |
| Page speed | Core Web Vitals from real visitors, described below. |
| Watch requests as they arrive | Live requests, described below. |
Page speed in browsers
The Page speed in browsers dialog reports the 75th percentile of three real-user metrics over the last seven days, plus the number of samples:
| Metric | Measures |
|---|---|
| LCP | Largest Contentful Paint: how long the main content takes to appear |
| INP | Interaction to Next Paint: how quickly the page responds to a tap or click |
| CLS | Cumulative Layout Shift: how much the layout moves while loading |
dply collects these by adding a small script to the HTML pages it serves from your build output. The script reports each page view's metrics back to dply. You don't need to install anything. When there are no samples in the last seven days, the row says so.
Tip
You can alert on LCP and on 5xx errors. See Alerts.
Live requests
Live requests is a real-time view of requests as they reach your app. Each row shows the time, method, status, response time in milliseconds, cache status, visitor country, and path.
- Filter by Method, Status, or a Path… substring.
- Choose Pause to freeze the view while you read it, then Resume.
- Choose Clear to empty the view.
- Choose CSV to download the recent request log as a CSV file.
The view loads with today's most recent requests and keeps up to 200 rows. If nothing appears, visit your app's URL to generate a request.
To follow requests from a terminal, use dply-edge logs (see CLI) or the logs endpoint of the HTTP API.
Pages & visitors
The Pages & visitors section shows the last 30 days of real page views. It has visitors, page views, views per visitor, a bar for each day's visitors, the top pages, referrers (the sites people came from), and countries. Static sites, server-rendered apps and container apps are all counted. Once a custom domain is live, only visits to your domains count: the *.on-dply.live address then mostly sees dply's checks and your own visits.
What counts as a page view:
- A
GETrequest answered with a2xxHTML page. Images, CSS, JavaScript, API responses, redirects and errors are left out. - Not a prefetch, and not from a bot or crawler (search engines, link previews,
curland similar tools). - Not from dply's own checks, such as URL monitors.
- Production only. Preview deployments are not counted.
Privacy. Visitors are counted without cookies, and no IP address or browser string is stored. Each page view keeps a code made from the visitor's IP and browser together with that day's date, scrambled with a key unique to your app, so it can't be reversed and changes every day. That makes a visitor unique per day: the 30-day visitor count is the sum of each day's visitors, so someone who comes back on three days counts three times. For a referrer, only the site's name is kept (for example www.google.com), never the full address, and visits from your own site aren't listed.
Counting starts from the app's first deploy after this feature shipped. Busy sites are sampled, so their visitor counts are a close estimate.
Apps delivered through your own Cloudflare account
If an app is delivered through a Cloudflare account you connected, dply does not collect its traffic. The summary says the stats live in your connected Cloudflare account and lists the hostnames to look up there. Response time and page speed still show.