Cloudflare: limits and logs
A Worker runs inside Cloudflare's limits, and a few of them shape the settings you choose. This page lists them and shows how to read the site's log. It is for whoever deploys to Cloudflare.
The limits below are taken from the product's own documentation and code comments. They were not tested independently for this guide, and Cloudflare changes its limits from time to time. Check Cloudflare's current documentation for your plan.
Limits that matter
| Limit | What it means for you |
|---|---|
| 50 outbound requests per invocation on the Workers free plan | Sending an announcement makes one request to your email service for each member. The site therefore sends in batches, EMAIL_BATCH_SIZE, which defaults to 15. Keep it under about 15 on the free plan. The admin page keeps asking until every member has been sent to. |
| D1: 100 bound parameters per statement | Big imports are grouped by the code to fit. You do not need to do anything. |
| D1: 50 statements per batch on the free plan | Bulk work is grouped in the same way. |
| Request body: 100 MB | The largest upload Cloudflare accepts. Keep UPLOAD_MAX_GALLERY_MB (default 100) under about 90, so a file and its envelope fit. Set it as a variable: UPLOAD_MAX_GALLERY_MB = "90". |
| 100,000 requests and 5 million D1 rows read a day on the free plan | From version 1.6.12 each page viewed is one request to the Worker and one read of the site's settings, as well as the API calls the page then makes. For a choir's site this is far inside the allowance. See Your choir's name in the page. |
| Workers cannot read audio files | The length of a rehearsal track is worked out in the admin's browser before the upload. Nothing to configure. |
The other upload limits are UPLOAD_MAX_IMAGE_MB (10), UPLOAD_MAX_FILE_MB (50) and UPLOAD_MAX_TRACK_MB (50), all under the 100 MB body limit. See Public file addresses and upload limits and Limits.
The 50-request limit is the free plan's. Check Cloudflare's current documentation for a paid plan before raising EMAIL_BATCH_SIZE. Sending speed is explained in Sender addresses, sending speed and testing.
Read the log
npx wrangler tail
This shows what the Worker logs, as it happens, while you use the site. Press Ctrl+C to stop. Run it from the folder that holds your wrangler.toml.
[config] lines
When the Worker first starts handling requests it checks the settings and logs each problem with a [config] prefix. It does this once for each running copy of the Worker (an "isolate"), not on every request, so a problem may appear only after a quiet period or a deploy. Examples you may see:
| Line | What to do |
|---|---|
[config] SITE_URL is not set: emailed login links need the site address | Set SITE_URL in [vars]. |
[config] ADMIN_USERNAME and ADMIN_PASSWORD are not set: nobody can log in to the admin panel | Set the two secrets, or use ADMIN_AUTH = "table". |
[config] EMAIL_PROVIDER is "log": ... | Choose a real email provider. |
[config] LICENSE_KEY is not set: ... | Set the LICENSE_KEY secret, or UPDATE_MODE = "off" to stop the notice. |
[config] UPDATE_MODE=self is not possible on Cloudflare Workers; ... | Remove UPDATE_MODE = "self". Updates on Workers are by hand. |
[config] wrangler.toml has no ASSETS binding: link previews and search engines are shown "Choir" in place of the site's name. ... | Your wrangler.toml is from before 1.6.12. The site works; add the two [assets] lines, together. See Your choir's name in the page. |
The full set of messages and what they mean is in Check your configuration.
A fatal error
If the Worker has no storage, every request fails and the log shows:
PUBLIC_BUCKET and PRIVATE_BUCKET R2 bindings are required (or set STORAGE_PROVIDER=s3)
Fix the [[r2_buckets]] blocks in wrangler.toml (the binding names must be exactly PUBLIC_BUCKET and PRIVATE_BUCKET), or use S3 storage, and deploy again.
From version 1.6.12, with the ASSETS binding in place, such an error no longer leaves the site blank. Requests to the API still fail, but pages and the build's files are served as they were built, and the log says once for each running copy of the Worker:
The site could not be started, so pages are served as built and the API is down: Error: PUBLIC_BUCKET and PRIVATE_BUCKET R2 bindings are required (or set STORAGE_PROVIDER=s3)
A visitor then sees the frame of the site, titled "Choir", with none of your content, and nobody can log in. The same happens when EMAIL_PROVIDER names a service whose secrets are not set.
Two other lines belong to pages:
| Line | What it means |
|---|---|
The page was served without the site's own title: and a reason | The site's settings could not be read from D1, or did not arrive within 1.5 seconds, so that one page went out as built. The visitor's browser fills in the name as it always did. Worth looking into only if it keeps happening. |
The page could not be read from the assets binding: and a reason | The Worker could not fetch the built page, and passed the request to Cloudflare's own file serving instead. |
Nothing on Workers applies database changes for you. If the log shows errors about missing tables or columns after an update, run the schema command again: see Update by hand.