Email reports

Anyone who can see a site can have a summary of it emailed to them every week, every month, or both. Reports are opt-in, per person and per site.

SubscribingCopy Anchor Link

• In the site: Site settings → Notifications → Email reports, with a switch per period. See an example shows the report you would get for the last complete period, with the site's real data.
• For all your sites at once: Account → Email reports lists every site you can read, across your organizations, with both switches.

A subscription belongs to a signed-in person: API keys cannot subscribe (403), nor can share links (401). It needs analytics:read on the site, which every organization role has. Someone who later loses access to the site gets no more reports; their subscription is kept, and reports resume if access returns.

The web app subscribes you with your browser session, through this request (a period left out keeps its state):

PUT /api/v1/sites/SITE_ID/reports
Content-Type: application/json

{"weekly": true}

{ "data": { "weekly": true, "monthly": false } }

When reports are sentCopy Anchor Link

Days follow the site's time zone, and a report goes out from 6 a.m. there on its day (the sending job runs every hour). A report not sent on its day, for example because the server was down all day, is not sent later. Each period is sent once per person.

What a report containsCopy Anchor Link

The subject names the site and the period, such as "Weekly report for Docs shop: Oct 19 – Oct 25, 2026" or "Monthly report for Docs shop: September 2026". The email has an HTML and a plain-text version:

• Traffic: visitors, pageviews and bounce rate, each with the previous period's value and the change (in percent, or in points for the bounce rate).
• Top sources and top pages: the five referrers with the most visitors, and the five pages with the most pageviews.
• Revenue: revenue, payments and conversion rate, in the site's default currency and under the site's credit model, with the same comparison. Shown only when you can see the site's revenue (revenue:read) and the site has a payment provider connected or payments in either period.
• Links to the site's dashboard, to unsubscribe from this report, and to manage your email reports.

The numbers are the dashboard's, over the site's whole traffic, without filters.

UnsubscribingCopy Anchor Link

Every report has an unsubscribe link, and mail apps that offer an unsubscribe button can use it directly: the email carries List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers (RFC 8058).

• Unsubscribing stops that one report (that site and period); the other period and other sites are not affected.
• The link needs no sign-in. It names one subscription and is signed, so it cannot be changed to point at another; it does not expire, and it can do nothing but unsubscribe.
• Switching the report off in the settings works the same.

The one-click endpoint is POST /api/v1/reports/unsubscribe?token=… (public; 200 with {"data": {"unsubscribed": true}}, 400 for a link that is not valid). GET on the same URL tells the unsubscribe page which site and period the link names, and whether it is still subscribed (404 for a link that is not valid).

API endpointsCopy Anchor Link

The preview answers with the report you would get for the last complete period (weekly by default, or monthly): its subject, a complete html document (show it sandboxed), its text, and the period's start and end days. An API key may read a preview too; its unsubscribe link is then a placeholder.

Self-hosted instancesCopy Anchor Link

Reports need the server's mail: Cloudflare Email Sending (CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_EMAIL_TOKEN) or an SMTP server (SMTP_URL). Without either, nothing is emailed: the server logs "mail not sent (no mail transport configured)" for each report instead, and that period counts as sent. Mail comes from MAIL_FROM, by default no-reply@ and your PUBLIC_URL's host name.

For mail apps to offer one-click unsubscribe, RFC 8058 also asks that the sending server signs messages with DKIM, covering the List-Unsubscribe and List-Unsubscribe-Post headers; Cloudflare always signs List-Unsubscribe (its headers reference). Cloudflare accepts the pair only with an https:// link, so an instance whose PUBLIC_URL is http:// sends reports through Cloudflare without it; the unsubscribe link in the email still works. Rotating BETTER_AUTH_SECRET voids the unsubscribe links of reports already sent. See the configuration reference.