DEV Community: HowardZlh

Wrangler authentication error 10000 with a per-Worker API token

HowardZlh — Mon, 12 Oct 2026 12:00:00 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

Between Sep 15 and Sep 18, 2026, at least seven Cloudflare Community threads had the same shape. An account-owned token had Individual Workers, Editor on one existing Worker. tokens/verify said active. Then wrangler deploy stopped on its first API call with Wrangler authentication error 10000.

I answered one of those threads on Sep 18. That afternoon a Cloudflare staff member posted that they'd fixed an issue behind it. The platform bug is gone, but the same error still shows up for reasons that are your config, and the checks below tell the two apart.

What happened between Sep 15 and Sep 18

The Workers roles and permissions page, which introduced per-Worker roles, was updated on Sep 15. Its Wrangler table says deploying an existing Worker needs Editor for that Worker, nothing more. People built tokens exactly that way and hit 403 with code 10000.

When (UTC)	What
Sep 15	Per-Worker roles documented. The first threads with 403 / 10000 appear
Sep 17, 09:25	Staff reply in Individual Worker Editor token rejected with error 10000: can't reproduce, and posts a successful response from a per-Worker Editor token
Sep 18, 14:50	Same thread: "We've fixed an issue that I believe affected this request"

If your token dates from that week and still fails, re-run the same request once before touching the token. If it now works, you were caught by that bug.

Why does tokens/verify say active when the deploy fails?

Because verify doesn't check permissions. Cloudflare's create token guide says the endpoint fetches the current status of the token. That tells you it exists and isn't expired or revoked. A 200 there and a 403 on a Worker aren't a contradiction, and verify can't tell you whether a scope is right.

There's also a second trap: there are two verify endpoints. User-owned tokens use /user/tokens/verify, and account-owned tokens use /accounts/<id>/tokens/verify. I tried both with a user-owned token I keep for analytics reads. The first returned "status": "active". The second returned 1000 Invalid API Token for the same token, same account.

The first API call wrangler deploy makes

In the workers-sdk source, validate-worker-props.ts reads the Worker's metadata from /accounts/<id>/workers/services/<name> before it uploads anything. That's where the threads failed, so it's the request to reproduce by hand:

curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/services/$WORKER" \
  -H "Authorization: Bearer $CF_TOKEN" | jq '{success, errors}'

With a working per-Worker Editor token this returns "success": true and the Worker's metadata. With code 10000 it's worth comparing against the successful response posted in the staff reply before rebuilding the token again.

The --env suffix: a name the token was never given

A per-Worker role is granted to a Worker name, and wrangler deploy --env production doesn't deploy the name at the top of your config. It deploys <name>-production.

My own home page Worker is app-home in wrangler.jsonc and deploys with --env production. Running the curl above on 2026-09-30 with a token that has no Workers permission at all gave three different answers:

Name requested	Response
`app-home`	`10090 This Worker does not exist on this account.`
`app-home-production`	`No access to the specified service.`
A made-up name	`10090 This Worker does not exist on this account.`

So "does not exist" can mean you asked for the unsuffixed name, and "no access" means the Worker exists but your token isn't allowed near it. If you scoped the token in the dashboard by picking the Worker from a list, check that you picked the suffixed one.

Four things a per-Worker Editor token still can't do

The same docs page lists the gaps. They're the reasons a correctly scoped token can still fail on the day the platform is fine:

Action	What it needs
Create a Worker that doesn't exist yet	Product-level Admin. Per-Worker roles can't apply to a Worker that isn't there
Add, change or remove Routes or Custom Domains	Editor on the Worker plus Zone, Workers Routes, Write on every affected zone
Custom Domains with per-Worker roles	Not supported yet. The Limitations section says support is planned
Query D1, read KV keys, list R2 objects directly	Permissions on that resource. Deploying with bindings doesn't need them

The second row catches deploys that look harmless. If your wrangler config lists routes or a custom_domain, a deploy that changes them needs the zone permission too. The docs say later deploys only need Editor, as long as they don't add, update or remove that connection.

A minimal CI token for one Worker

For a deploy-only pipeline I'd build the token from the table up. Start with Individual Workers, Editor on the exact deployed name, suffix included. Add Zone, Workers Routes, Write on the zone only if the pipeline changes routes. Add nothing for bindings unless a step queries D1 or KV directly.

My own home page deploy token is older than per-Worker roles and has Workers Routes and DNS edit on the zone, because its config binds two Custom Domains. I can't shrink it to one Worker yet, and that's the third row of the table in practice. Scoped tokens with an expiry are also item 11 in my Cloudflare zone security checklist, which has the read-only command for listing the tokens you already have.

The usage collector I run needs one Account Analytics Read token and nothing else. The hosted version is a one-question form today, not a product: guard.guushu.com.

Original, with any later corrections: guushu.com/notes/wrangler-error-10000-per-worker-token/

Cloudflare Email Sending activity log shows only failures: 3 checks

HowardZlh — Sun, 11 Oct 2026 12:00:00 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

A Worker sent mail through Cloudflare Email Service, the messages were arriving, and the sender had checked the raw sources to be sure. The Cloudflare Email Sending activity log still listed only failures, and Analytics showed 0 successes and a 100% failure rate. I answered that thread on Cloudflare Community on Sep 24.

You don't have to take the dashboard's word for it, or anyone's guess. The Activity log reads a GraphQL dataset you can query yourself, and the answer tells you which of three problems you have.

Does the Activity log have its own data?

No. The Email Service logs page says the Activity log surfaces the same per-event data as the emailSendingAdaptive and emailRoutingAdaptive GraphQL datasets. The analytics page says the dashboard charts are queried from the GraphQL Analytics API. If successful sends were recorded, a direct query finds them.

That turns a vague "the dashboard looks wrong" into a yes or no question. Either the rows exist and the dashboard is dropping them, or they were never written for the zone you're looking at.

The GraphQL query, by status and sendingDomain

The Email Service metrics and analytics page has a ready-made query called Email sending operations. It groups by date and status. I add sendingDomain, which is one of the documented dimensions and the one that matters here:

query EmailSendingByStatus($zoneTag: string!, $start: Date!, $end: Date!) {
  viewer {
    zones(filter: { zoneTag: $zoneTag }) {
      emailSendingAdaptiveGroups(
        filter: { date_geq: $start, date_leq: $end }
        limit: 10000
        orderBy: [date_DESC]
      ) {
        count
        dimensions { date status sendingDomain }
      }
    }
  }
}

Three details from the same page that trip people up. The token needs Analytics Read. zoneTag is the zone ID, not the account ID, because these are zone-level datasets. Data is kept for 31 days, so a date range older than that returns nothing.

To run it from a terminal, save the query as q.graphql:

jq -n --rawfile q q.graphql \
  --arg z "$ZONE_ID" --arg s 2026-09-01 --arg e 2026-09-30 \
  '{query: $q, variables: {zoneTag: $z, start: $s, end: $e}}' \
| curl -s https://api.cloudflare.com/client/v4/graphql \
    -H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" -d @- \
| jq '.data.viewer.zones[0].emailSendingAdaptiveGroups'

Reading the result: rows, an empty list, or only failures

delivered rows come back. The data exists and the dashboard isn't showing it. That's a clean report for support: the query, the output, and a screenshot of the log for the same range.

An empty list comes back. That isn't an error, and it doesn't prove the dashboard is broken. When I ran this on my own zone for September, emailSendingAdaptiveGroups returned [], because I don't send through Email Service. The routing version of the same query returned 30 rows from the same zone. Empty means nothing was recorded under this zone ID.

Only failure statuses come back. Then the log is probably right and the mail you saw arrive went some other way, or through another zone. Keep reading.

Is the From domain on a different zone?

It's the first thing I'd check when the list is empty or short. These datasets are per zone, so a Worker whose From address is on another zone should log its successes under that zone. The docs don't say this in one sentence, so treat it as my inference from the zone-level design, not a documented rule.

The cheap test is in the dashboard. Go to Compute, Email Service, Email Sending, and pick the account-wide view instead of one domain before opening Analytics. If the missing sends show up there, the zone was the problem, not the log.

Delivery failed and Failed are different problems

Expand one failure before changing anything. The logs page lists five sending statuses, and two of them sound alike:

Status	Meaning per the docs	Where to look
Sent	Accepted and queued	Wait, or check for a later event
Delivered	Recipient server accepted it	Nothing to fix
Delivery failed	Bounced, hard or soft	Recipient address, their mail server response
Rejected	Recipient is on your suppression list	Suppressions page
Failed	Configuration or authentication problem	Sending domain setup, DNS, the Worker binding

A log full of Delivery failed while mail is landing would be odd. A log full of Failed points at the sending domain's own setup. The docs also have a Delivery failure analysis query that groups by errorCause and sendingDomain, and the per-event emailSendingAdaptive dataset adds errorDetail.

What I'd hand support

If delivered rows exist and the dashboard shows 100% failed, the sender is right that something is off on Cloudflare's side. The report that gets a quick answer is short: the zone ID, the date range, the GraphQL output with status and sendingDomain, and the Activity log screenshot for the same range.

The receiving side works the same way. Its dataset is emailRoutingAdaptiveGroups, and a blank routing log has its own diagnosis, which I wrote up in Cloudflare Email Routing stopped working. If you're only receiving, the Cloudflare Email Routing support address setup is the simpler place to start.

The shared inbox I'm sketching sits on the receiving side of Email Service, one support@ that two people can answer. It's a waitlist page today, not a product: guard.guushu.com/inbox.

Original, with any later corrections: guushu.com/notes/cloudflare-email-sending-activity-log/

Animated GitHub contribution snake for your profile README, your repos, and your orgs

HowardZlh — Sat, 10 Oct 2026 13:15:00 +0000

GitHub keeps a contribution calendar for user accounts and nothing else. A repository doesn't have one, and neither does an organization. That's why every contribution snake you've seen sits on somebody's profile page.

I wanted the snake on two pages that don't qualify: the README of stellar-odyssey, and the profile of the FailRouter organization. So I wrote github-action-shares, a GitHub Action that builds the calendar itself and draws three animated SVGs from it. It took two days, from v1.0.0 to v1.2.0.

What lands in your README

One run writes eight SVGs (a light and a dark version of each) and a stats.json:

File	What it shows
`snake.svg`	a snake that eats the year, nearest square first
`heatmap.svg`	the familiar grid, filling in week by week
`skyline.svg`	a 3D isometric skyline with the busiest day and the longest streak
`activity.svg`	the snake, or a one-line summary while the project is young
`stats.json`	total, busiest day, streaks, first and last active day

The heatmap and the skyline are drawn from the same year as the snake at the top of this post:

All three draw the same daily numbers. Pick one per page. Three charts of one dataset make a reader scroll past the same year three times.

A young repo doesn't show a year of empty squares

This was the first thing that looked wrong. A repository that is two months old, drawn on GitHub's 53-week grid, is forty-five weeks of grey followed by a few green columns. To a visitor that reads as "barely touched", which is the opposite of what a project activity chart is for.

window: auto starts the grid at the week of the first commit, at least eight weeks wide. Stellar Odyssey started on 2026-07-19, so its grid is twelve weeks, not fifty-three:

Below ten active days even a cropped grid is mostly empty, so activity.svg turns into a sentence. The FailRouter org page shows that state right now:

On its tenth active day the same URL starts serving the snake. Nobody edits the README for that, and no bot commits to it either.

Set it up for a repository in three steps

Add the workflow. Save this as .github/workflows/readme-showcase.yml:

name: README showcase
on:
  schedule: [{ cron: "23 3 * * *" }]
  workflow_dispatch:
permissions:
  contents: write
jobs:
  art:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with: { fetch-depth: 0 } # git log needs the full history
      - uses: HowardZlh/github-action-shares@v1
        with: { source: repo, git-path: ., window: auto, out-dir: dist }
      - uses: crazy-max/ghaction-github-pages@v5
        with: { target_branch: output, build_dir: dist, keep_history: false }
        env: { GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }

Run it once. Open the Actions tab, pick the workflow, and press Run workflow. After that the nightly schedule takes over.

The run takes 10 to 15 seconds and creates an output branch with the images:

Point your README at it. Replace OWNER/REPO:

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/OWNER/REPO/output/activity-dark.svg">
  <img alt="OWNER/REPO commits since the first one" src="https://raw.githubusercontent.com/OWNER/REPO/output/activity.svg">
</picture>

<picture> picks the dark file for visitors on GitHub's dark theme. Write a real alt; screen readers read it and image search indexes it.

Your profile and your organization

On a profile, source: user reads your contribution calendar through GraphQL, so private work counts too if you've ticked Private contributions in your profile settings. The profile example pairs the snake with github-profile-3d-contrib for the 3D calendar, and adds three shields.io badges that read their numbers from stats.json. Here is my profile in dark mode:

For an organization, source: org sums the commit statistics of every public, non-fork repository. The same action has a second command, readme, that rewrites two marked blocks in a README: a project table sorted by stars and a recent-activity list. On an org page that list includes lines like "⭐ someone starred your-repo", which is social proof a personal profile can't show.

You can copy both setups from examples/, and the tutorial walks through each one with the same screenshots.

How it works

Three sources, one calendar. A repository is counted from git log dates in the checkout. An organization is the sum of /repos/{repo}/stats/commit_activity across its public repos. A user comes from the GraphQL contributionCalendar, the same numbers GitHub draws on the profile. Everything after that step only sees a list of { date, count }.

Animation without JavaScript. GitHub serves README images through its camo proxy as plain <img> tags. Scripts never run there, and hover events never fire. What does work is CSS @keyframes and SMIL. The heatmap and the skyline use keyframes with a per-cell delay. The snake is a <rect> per body segment moving along an <animateMotion> path, and each square it eats has its own <animate> that turns it grey at the exact step the head arrives.

The snake takes the short way. It enters at the top left, always heads for the nearest uneaten green square one cell at a time, and leaves through the nearer edge. The step length is chosen so a loop lasts between 8 and 30 seconds, whether the year had five active days or three hundred.

My first version swept all 371 cells in order. On a sparse year it spent ten seconds crawling over grey before it reached anything green.

Nothing lands on your default branch. The images go to an output branch through crazy-max/ghaction-github-pages with keep_history: false, so that branch is always one commit. If merging to main deploys your site, a nightly art refresh never triggers it.

Quartile colours, like GitHub. The four greens are cut at the quartiles of your non-zero days, not at a fraction of the maximum. One 68-commit day doesn't wash the rest of the year out to the palest shade.

Respectful defaults. Under prefers-reduced-motion: reduce the SVGs show the final frame. Each one has role="img", a <title> with the real number and a <desc> with the date range. A longest streak under three days is left out of the text, because "longest streak: 1 day" helps nobody.

Zero dependencies. It's a composite action that runs node bin/showcase.mjs: about 850 lines of JavaScript using the built-in fetch and string templates. There's no node_modules to audit and no Docker image to pull. Tests use node:test against a throwaway git repository and a fake fetch, and CI fails under 90% line coverage.

Tools it stands on

Tool	Job
GitHub Actions, composite action	runs the generator on a schedule
Node.js built-ins (`fetch`, `node:test`)	API calls, tests, coverage, no packages
GitHub REST and GraphQL APIs	commit statistics, contribution calendar, stars, events
crazy-max/ghaction-github-pages	pushes the SVGs to the `output` branch
raw.githubusercontent.com	serves the images to your README
shields.io dynamic JSON badges	live numbers from `stats.json`
github-profile-3d-contrib (optional)	the 3D calendar on a profile

Things I ran into

Not every badge host gets through camo. Visitor-counter images from komarev.com load in a browser and return 404 Cannot proxy the given URL inside a README. Copy the image address from the rendered page and curl it before you rely on a badge.
The org's own .github repo broke the org chart. Every commit to the profile README made GitHub recompute that repo's statistics, and the API kept answering 202 Accepted. The action now skips .github and skips a repo whose statistics are still cold with a warning instead of failing the run.
Pull request events lost their titles. Since 2025 the Events API ships pull request events without title or html_url, so the activity list fetches /pulls/{n} for the few it shows.

For comparison, here is how it differs from the snake most profiles use:

	Platane/snk	github-action-shares
Works for	users	users, repos, orgs
Eating order	one colour level after another	nearest square first
Loop on a busy year I measured	about 85 s	8 to 30 s by design

Limits

README images can't be interactive. If you want tooltips or zoom, link the image to a page you host. The org chart only sees public repositories, and it inherits GitHub's 52-week window for commit statistics. GitHub pauses scheduled workflows in a public repository after 60 days without activity, so a dormant repo's chart stops refreshing until you re-enable it.

Try it

Copy the workflow above into one of your repos, press Run workflow, and paste the five lines of <picture> into the README. The whole thing takes about two minutes, most of it waiting for the first run.

HowardZlh / github-action-shares

Animated contribution heatmap, snake and 3D skyline SVGs for any GitHub repo, org or user, plus auto-updated stars and activity in your README. Zero-dependency GitHub Action, MIT.

Animated GitHub README stats for any user, organization or repository

English | 中文

A GitHub Action that draws a contribution heatmap, a snake that eats it, and a 3D skyline, as animated SVGs, for a single repository or a whole organization as well as for a user account. It also keeps a star-sorted project table and a recent-activity list in your README up to date. No dependencies, MIT.

That snake is eating a year of @HowardZlh's contributions, redrawn every night by showcase.yml. A two-month-old repo gets a grid that starts at its first commit instead of a year of empty squares, and a one-line summary until it has ten active days.

Jump to: What you get · On real pages · Quick start · Profile · Organization · Inputs · Tutorial · How it works

What you get

Every SVG comes in a light and a dark…

View on GitHub

If you put it on a page, open a PR that adds your repo to the Used by list. And if it saved you an evening, a star on the repo helps the next person find it.

Cloudflare Pages not updating after deploy: the s-maxage trap

HowardZlh — Sat, 10 Oct 2026 12:00:00 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

A new Pages deploy showed Success and was marked Production, yet the custom domain and <project>.pages.dev both kept serving the old index.html for over a day. I answered that thread on Cloudflare Community on Sep 28. Cloudflare Pages not updating after deploy on both hostnames at once points at a header, not at the deploy.

The headers in the post said it all: cf-cache-status: HIT, an age of about 30 hours, and cache-control: public, s-maxage=604800. Two more redeploys with different content hashes didn't change a thing.

Why is Cloudflare Pages still serving the old version?

Because something told the CDN it could keep that HTML for a week. The Pages default for a cacheable asset is public, max-age=0, must-revalidate, and Pages never adds s-maxage by itself. A s-maxage=604800 comes from the project: a _headers rule, a Pages Function, or an advanced mode _worker.js.

You can see the default on any Pages site that doesn't override it. I run two Pages projects, and on 2026-09-30 both returned the same thing on the custom domain and on pages.dev:

curl -sI https://<project>.pages.dev/ | grep -iE "cache-control|cf-cache-status|^age"

cache-control: public, max-age=0, must-revalidate
cf-cache-status: DYNAMIC

That's what "no custom caching" looks like. The Headers section of the Serving Pages page lists it under headers sometimes added, for any request without an Authorization or Range header.

Where the s-maxage usually comes from

The most likely source is a _headers file in the build output with a catch-all rule, the kind that gets copied from a performance guide:

/*
  Cache-Control: public, s-maxage=604800

That rule matches every path, HTML included. Search the build output as well as the source, because frameworks copy public/ into it:

grep -rn -i "s-maxage" dist/ public/ functions/ _worker.js 2>/dev/null

The _headers page has a caution worth knowing here. Rules in _headers don't apply to responses generated by Pages Functions. If an SSR framework or _worker.js renders the page, the header is being set in that code's Response, and the grep above will find it in functions/ or the worker file.

How to purge the Pages cache without a zone

You mostly can't, and that's the uncomfortable part. The Serving Pages page describes one purge path: go to your zone and use Caching, Configuration, Purge Everything. A project on pages.dev with a custom domain on some other DNS provider has no zone in the account to purge.

The same page's Asset retention section says assets are cached per data center with a one-week TTL, and after a new deploy the old ones can stay up to a week. That matches the thread. The redeploys didn't evict HTML cached under the project's own s-maxage.

So the fix is two steps, and the order matters:

Remove the rule that sets s-maxage on HTML and deploy. Otherwise every future deploy starts a fresh seven-day clock.
Wait out the copies already cached. Worst case that's the week the header promised.

If the custom domain is on a zone in your account, Purge Everything on that zone clears it there. The pages.dev hostname isn't part of your zone, so it can stay stale until retention runs out.

Check the new build on its deployment URL

Every deployment also gets its own address. The preview deployments page says it's hash-based, like <hash>.<project>.pages.dev, and atomic, so it keeps pointing at that exact build. Open it from the deployments list in the dashboard.

It's a different hostname, so it shouldn't share the cached HTML from the production hostnames. I haven't tested that part myself. It's still the quickest way to prove the new build is correct while you wait, instead of redeploying a third time.

Cache Rules on a custom domain cause the same symptom

Even with clean headers, a custom domain can go stale if its zone caches HTML. The Serving Pages page says it plainly: adding caching to your custom domain may lead to stale assets after a deployment, and it can also break Pages redirects and Functions.

If the custom domain sits on your zone, read its Cache Rules. Both of my Pages projects sit on custom domains in my own zone, and DYNAMIC is what those custom domains return: the HTML isn't being held at the edge. The read below uses the same cf() helper as my Cloudflare zone security checklist:

cf /zones/$ZONE_ID/rulesets/phases/http_request_cache_settings/entrypoint \
  | jq '.result.rules[] | {description, expression, action_parameters}'

A rule that sets an Edge TTL on everything, or on /, is the same bug in a different place.

Long cache headers that are safe on Pages

Long caching is fine for files whose names change when their content does. The _headers page's own example scopes it to one folder:

/static/*
  Cache-Control: public, max-age=31556952, immutable

Put fingerprinted files there and leave HTML on the default. Bundlers like Vite and Astro already put hashes in asset names, so the only thing to avoid is a /* rule. HTML is the file that has to change on every deploy, and it's the one that must never get a week-long shared cache.

A purge button for Pages projects without a zone would be a fair feature request. I couldn't find one in the docs.

Cache Rules and other zone settings that change quietly are what the daily drift check I'm sketching would diff. It's a one-question form today, not a product: guard.guushu.com/zone-audit.

Original, with any later corrections: guushu.com/notes/cloudflare-pages-not-updating-after-deploy/

Cloudflare Email Routing stopped working? Check nameservers first

HowardZlh — Fri, 09 Oct 2026 12:00:00 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

The dashboard said Enabled, DNS records said Locked, and all 49 routing rules were still there. When Cloudflare Email Routing stopped working for someone I was helping in September, the only honest signal was the Activity log. Its last row was three days old, and there was nothing after it.

That's not a rejection. Cloudflare wasn't receiving any mail at all. The registrar had reset the domain's nameservers, so the Cloudflare zone was no longer the one the internet was asking. Two dig commands show this in under a minute.

What does a blank Email Routing Activity log mean?

It means no sender reached Cloudflare's MX for that period. Every message Cloudflare does receive leaves a row with a status, even when it fails. The Email Service logs page lists them: Forwarded, Handled, Dropped, Rejected, Delivery failed and Error. No row at all means no delivery attempt arrived.

That splits the problem in two before you touch anything:

Activity log shows	What happened	Where to look
Rows with Rejected or Delivery failed	Cloudflare got it, the next hop failed	Destination mailbox, SPF / DKIM / DMARC
Rows with Forwarded, but mail is missing	Delivered	Spam folder and filters at the destination
Nothing after a certain day	Cloudflare got nothing	Nameservers, MX, domain status

One caveat from my own zone. It routes 1 to 4 messages a day, and in September three days had zero rows in the emailRoutingAdaptiveGroups GraphQL dataset, which the Activity log reads from. They were just quiet days. A gap only means something if the address normally gets mail every day, so send yourself a test message before reading anything into it.

Two dig commands that show a nameserver change

Ask a public resolver, not the one on your laptop:

dig +short NS yourdomain.com @1.1.1.1
dig +short MX yourdomain.com @1.1.1.1

A healthy Email Routing zone looks like this. It's my own zone, run on 2026-09-30:

craig.ns.cloudflare.com.
priscilla.ns.cloudflare.com.

22 route3.mx.cloudflare.net.
84 route1.mx.cloudflare.net.
98 route2.mx.cloudflare.net.

The @1.1.1.1 isn't decoration. When I first ran both commands for this note, my Mac's resolver returned nothing for NS and MX while it answered SOA fine. A public resolver gave the right answer straight away. An empty result from a local resolver proves nothing.

If the NS line shows anything other than two *.ns.cloudflare.com hosts, and MX comes back empty, the nameservers were changed at the registrar. Cloudflare's copy of your records is intact. Nobody is reading it.

Find the day it changed in WHOIS

whois yourdomain.com | grep -iE "updated date|name server|status"

If the Updated Date matches the day mail stopped, that's your change. In the case I looked at, it matched to the day. The new nameservers were ns-cloud-a*.googledomains.com hosts, and their SOA serial was 1, which is what a zone that was created moments ago looks like.

A Domain Status of clientHold or serverHold is a different problem with the same symptom. The registry has suspended the domain, so nothing resolves at all. That one gets fixed at the registrar, not in Cloudflare.

Why the dashboard still says Enabled and Locked

The Email Routing overview reads Cloudflare's copy of the zone. As far as I can tell, Locked means the MX and SPF records in that copy match what Email Routing needs. It can't know that resolvers stopped asking that copy.

Cloudflare does notice eventually, on its own schedule. Its domain status page says a zone that fails repeated nameserver checks moves to Moved. On the Free plan, a Moved zone is deleted 7 days later. Your DNS records go with it, and Email Routing rules live in that zone too.

So there's a deadline. Check the zone status right away:

curl -s "https://api.cloudflare.com/client/v4/zones?name=yourdomain.com" \
  -H "Authorization: Bearer $CF_TOKEN" | jq '.result[0].status'

"active" is fine. "moved" means the week has started.

Who changes nameservers when you didn't?

Usually the registrar, or a site builder acting through it. The user in my case had a Squarespace notification from around the same day, and the domain's A record pointed at a Shopify IP. Squarespace's help page on domain nameservers says custom nameservers disconnect the domain from the site. Reconnecting a site from that dashboard, or the Use Squarespace nameservers button, puts Squarespace's defaults back.

Other registrars have their own versions of this: a domain transfer that lands on default DNS, a "connect to website" wizard, an expired-then-renewed domain. The common thread is a change made outside Cloudflare, which Cloudflare's dashboard can't show you.

The fix, in order

At the registrar, set the nameservers back to the two shown on your Cloudflare zone's Overview page.
Re-run dig +short NS yourdomain.com @1.1.1.1 until it shows Cloudflare. Squarespace quotes up to 48 hours, and it's usually much faster.
Confirm the zone status is active, then open Email Routing settings. If it flags MX or TXT records as missing, re-add them from there.
If a site builder needs the domain, add its A or CNAME records in Cloudflare DNS instead of connecting from the builder's side. That path is what reset the nameservers in the first place.

What happens to mail sent during the outage?

Most of it is still in retry queues. With no MX record, a sender falls back to the domain's A record and tries to deliver there. If that host doesn't take mail, the sender keeps retrying. RFC 5321 says the give-up time generally needs to be at least 4 to 5 days.

So mail from the last few days may arrive on its own once MX is back. Anything older than the sender's retry window already bounced to the sender. Nothing you do on the Cloudflare side brings that back, so it's worth telling the people who were likely to write.

Nameservers and MX aren't in my Cloudflare zone security checklist yet, and after this case they should be. The two dig lines above are the whole check. If you run a Cloudflare Email Routing support address, they're the first thing to try when it goes quiet.

Nameservers and MX drifting while the dashboard stays green is the gap I'm sketching a daily check for. It's a one-question form today, not a product: guard.guushu.com/zone-audit.

Original, with any later corrections: guushu.com/notes/cloudflare-email-routing-stopped-working/

Cloudflare free plan WAF rules I kept after 7 days of scanner logs

HowardZlh — Thu, 08 Oct 2026 12:00:00 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

These are the Cloudflare free plan WAF rules running on my zone today: three custom rules and one rate limiting rule. I got there by reading a week of firewall events, and by undoing one change that blocked my own images.

The short version: path rules do most of the work. The rate limit is where you hurt yourself.

What 7 days of Cloudflare security events looked like

Between September 17 and 24, the zone saw about 34,000 requests. 55% of them hit a security action. The events sample I pulled had 5,208 rows from 920 IPs.

None of it was aimed at me. It was the same background noise every public hostname gets: .env files, .git/config, WordPress logins, a React RCE probe for CVE-2025-55182, empty user agents, Go-http-client.

The part that surprised me was cost. Blocked requests never reach the Worker. My busiest Worker peaked at 786 requests in a day, against a free allowance of 100,000.

To see your own, the GraphQL Analytics API has a firewall events dataset. On Free, it's sampled, and the hourly query budget is small, so don't loop it.

{
  viewer {
    zones(filter: { zoneTag: "<zone id>" }) {
      firewallEventsAdaptive(
        limit: 100
        filter: { datetime_geq: "2026-09-17T00:00:00Z" }
        orderBy: [datetime_DESC]
      ) { action source clientIP clientRequestPath userAgent clientASNDescription }
    }
  }
}

Is it an attack or background scanning?

Background scanning, in my case. Look at three things: the paths (secret files and CMS logins you don't have), the source network (cloud and VPS ranges, not home ISPs), and the timing (dozens of paths from one IP inside a second). If all three match, it's an automated scanner, and blocking it at the edge is enough.

One warning before you trust a report. The first analysis I got, written by an AI assistant from the same API data, listed /estimate as an unknown endpoint probe. That's my calculator page. It also counted /zh-Hant/ and /sitemap.xml. Check every "attack path" against your own routes.

Two path rules: block WordPress and secret-file paths

Free gives you 5 custom rules and no regex, so every rule is a chain of contains. I use two for paths.

The WordPress one. I don't run WordPress anywhere, so nothing legitimate matches:

(http.request.uri.path contains "/wp-admin") or (http.request.uri.path contains "/wp-includes")
or (http.request.uri.path contains "/wp-content") or (http.request.uri.path contains "/wp-json")
or (http.request.uri.path contains "/xmlrpc.php") or (http.request.uri.path contains "/wp-login")
or (http.request.uri.path contains "/wlwmanifest.xml") or (http.request.uri.path contains "/wordpress/")
or (starts_with(http.request.uri.path, "/wp/"))

The secret-file one is longer. The core of it:

(http.request.uri.path contains "/.env") or (http.request.uri.path contains "/.git/")
or (http.request.uri.path contains "/.aws/") or (http.request.uri.path contains "/.docker/")
or (http.request.uri.path contains "/credentials.yml") or (http.request.uri.path contains "/phpinfo")
or (http.request.uri.path contains "/info.php") or (http.request.uri.path contains "/dump.sql")
or (http.request.uri.path contains "/_profiler")

contains "/.env" already catches .env.production and /api/.env. You don't need a line per variant.

Why bother, if those files don't exist? A path rule blocks the first request. A rate limit only kicks in after the threshold, so a slow scanner walks under it forever.

That's all four rules on my zone as of 2026-09-28, with the dashboard's event count next to each. IPs are replaced with documentation addresses.

The user agent rule: block tool clients, and pay for it

The other custom rule blocks two known IPs plus any user agent containing curl, Go-http-client, python, scrapy or fasthttp.

It works. It also bit me. My own ops notes said Python and Go clients were allowed. The live rule blocked both, and a bare curl https://guushu.com/ returns 403 today. When I check my own site now, I send a browser user agent.

Before copying this rule, list what calls your zone: webhooks, uptime checks, your own scripts. If any of them use a default library user agent, they're gone. This is the rule most likely to cause a quiet outage.

The one free rate limiting rule, and how it 429'd my own images

Free gets one rate limiting rule, counted per IP, with a fixed 10-second window and a fixed 10-second block.

The AI report suggested dropping mine from 20 to 10 requests per 10 seconds. I did. Three days later, an image-heavy page on another subdomain was returning 429 on its own first screen. AI search crawlers were getting rate-limited too: GPTBot, ClaudeBot, PerplexityBot.

The fix was to stop counting things that aren't worth counting:

((http.host eq "guushu.com") or ends_with(http.host, ".guushu.com"))
and not (http.request.uri.path.extension in {"js" "css" "png" "jpg" "jpeg" "gif" "webp" "avif" "svg" "ico" "woff" "woff2" "ttf" "json" "map" "txt" "xml" "webmanifest"})
and not cf.client.bot

Back at 20 requests. The test: 40 concurrent HTML requests from one IP gave 20 × 200 and 20 × 429. 40 concurrent static requests gave 40 × 200. cf.client.bot is true only for Cloudflare's verified bots.

Does a 429 on Googlebot mean you're blocking Google?

Not necessarily. My logs had 107 rate limit events with a Googlebot user agent. Every one came from Google Cloud customer ranges, not the crawler. Google publishes its crawler IP ranges; check the source IP before you loosen anything. Real Googlebot and Bingbot had zero blocks.

Zone settings I changed, and ones I left off

On the settings side, I moved minimum TLS to 1.2, turned on HSTS, and left Bot Fight Mode, AI Labyrinth and the Free managed ruleset on. The full list with a curl for each is in my Cloudflare zone security checklist.

One caution on HSTS. My header now says includeSubDomains; preload. Preload is hard to take back, so be sure every subdomain serves HTTPS before you add it.

I left three things off. Under Attack Mode puts a challenge in front of every visitor, which is a lot of friction for background noise. mTLS wants a client certificate that none of my visitors have. Hotlink protection solves a problem these scans don't have.

A week later, the numbers I'll look at are simple: whether rate limit events from home ISPs stay near zero (before the fix, about 3 of 69 blocked IPs were residential), and whether my own pages still load in one go.

If you run more than one zone and want this kind of drift flagged daily, there's a one-question form, not a product yet: guard.guushu.com/zone-audit.

Original, with any later corrections: guushu.com/notes/cloudflare-free-plan-waf-rules/

Cloudflare Email Routing vs Google Workspace vs Zoho for support@

HowardZlh — Wed, 30 Sep 2026 02:08:42 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

My own support@ runs on the first column of the table below, and for one person reading mail that's plenty. The comparison of Cloudflare Email Routing vs Google Workspace vs Zoho only gets interesting once you ask three things. Do you just need to receive at your domain? Do you need to reply as that address from a real mailbox? Do two people need to handle the same address?

Each question knocks out a column. I left prices out of the table on purpose. They change, and the pricing pages are one click away. What each option can do doesn't.

Which option fits which need?

Receive only: Email Routing, $0, 10 minutes.

Reply as support@ from a mailbox: Zoho's free tier or one Workspace seat is the shortest path.

Two or more people on one address: run one of the self-hosted inboxes built on Email Routing, or pay someone to run that shape for you. The rest of this note is detail on those three lines.

The comparison table

Checked 2026-09-16 against Email Routing, Google Workspace pricing and Zoho Mail pricing.

	Cloudflare Email Routing	Google Workspace (1 seat)	Zoho Mail	Self-hosted on Cloudflare
Software cost	$0	Per seat, monthly	Free tier; paid per user	$0 code; all three say they run on Workers Free for small teams, R2 activated separately
Receives at your domain	Yes	Yes	Yes	Yes, via Email Routing
Stores mail	No, forwards only	Yes	Yes	Yes, your D1 / R2
Reply as support@ later	No	Yes	Yes	Yes, via Email Sending or Resend
Multiple addresses	Up to 200 rules per domain, plus catch-all	Aliases on one seat	Aliases; limits per plan	Unlimited patterns, one Worker
Two people, one address	One rule, one destination; fan-out needs a Worker	Delegation / Groups	Shared mailbox on paid tiers	Yes, no seat pricing
Max message size	25 MiB	Per their docs	Per their docs	25 MiB (Email Routing limit)
Programmable	Yes, Email Workers	Gmail API	Zoho API	It is your code
Setup	10 min	DNS verify + DKIM	DNS verify + DKIM	1 to 3 h, then you run it
DNS you hand over	MX + SPF	MX + SPF + DKIM + TXT	Same	MX + SPF, plus DKIM if you reply

The fourth column is three projects, checked 2026-09-16. cloudflare/agentic-inbox is Cloudflare's own (Apache-2.0, Workers + D1). HQBase is AGPL-3.0 (Workers + D1 + R2 + Queues). ResolveHQ is source-available, not open source (Email Routing + Resend + D1 + R2 + Queues).

Scope and license differ, the stack doesn't. Details and the 30-line handler are in Cloudflare Email Worker inbox.

What the table does not say

Email Routing is a forwarder that can run code. A rule can target a Worker, and the Worker gets the raw MIME. Nothing else in the table lets you put a function between the MX record and the mailbox for free.

Workspace is the one that just works: one seat, one mailbox. You pay for that seat every month, even for an address that might get ten messages a week. Its MX records also replace Cloudflare's.

Zoho's free tier is real. It's fine for one person. The shared-mailbox features sit on paid plans, which puts Zoho in the same spot as Workspace once there are two of you.

The self-hosted column works, and you're the one running it. Two people on one support@ with no seat pricing already exists three times over on GitHub, one of them maintained by Cloudflare. The catch: you keep the D1 schema migrated, and you get paged when the reply path breaks.

Who covers two people on one support@ without running it yourself?

Workspace and Zoho do it with a second seat. The self-hosted projects do it for the cost of running them. Nobody in the table offers the same Worker-plus-D1 shape as a hosted service, for people who'd rather not run one more thing.

If the first column is all you need, the setup and its three limits are in Cloudflare Email Routing support address.

The hosted half of the fourth column, the same Worker-plus-D1 shape with someone else on the pager, is a waitlist page today, not a product. The form asks which address you route: guard.guushu.com/inbox.

Original, with any later corrections: guushu.com/notes/cloudflare-email-routing-vs-google-workspace-zoho/

Cloudflare Email Routing support address: setup and 3 limits

HowardZlh — Tue, 29 Sep 2026 02:01:05 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

A Cloudflare Email Routing support address is the cheapest way to get support@yourdomain.com into a mailbox you already read. It costs $0, needs no mail server, and takes about 10 minutes. I set one up for my own domain earlier this month, and that address now gets both my metrics alerts and my support mail.

That second part is where this note ends up. Setup first, then the three limits.

What Cloudflare Email Routing does and does not do

Email Routing takes over your domain's MX records and forwards inbound mail to an address you've verified. It stores nothing.

Sending is a separate product, Email Sending, under the same Email Service umbrella. On its own, Routing is a free forwarder that lives in your DNS.

How do you set up a support address on Email Routing?

Enable Email Routing on the zone, verify one destination mailbox, and add one rule for support. Cloudflare writes three MX records and one SPF TXT record for you. The destination gets a verification link, and nothing forwards until someone clicks it. It's three dashboard screens and one dig to confirm.

Step 1: Enable it

Dashboard, Compute, Email Service, Email Routing, Onboard Domain, then pick your zone. If the zone already has MX records pointing somewhere else, Cloudflare flags the conflict and offers to replace them. There's no "run both" mode.

Once it's on, the row reads Enabled and Locked. Locked means Cloudflare manages those MX records and won't let you edit them by hand.

dig +short MX yourdomain.com
# route1.mx.cloudflare.net.
# route2.mx.cloudflare.net.
# route3.mx.cloudflare.net.

Step 2: Add a destination

Click Destination addresses on the same page and add the personal mailbox you already read. Cloudflare emails it a verification link. Until that's clicked, rules pointing at the address do nothing. Destinations belong to the account, so one verified mailbox works for every zone you onboard.

Step 3: Create the rule

Open your domain, then Routing rules, Create routing rule: email pattern support, action Send to an email, and pick the destination. You can also turn on Catch-all so anything@yourdomain.com lands somewhere instead of bouncing.

# from any other account
echo "ping" | mail -s "routing test" support@yourdomain.com

Ten minutes. Most tutorials stop here, and so did I at first.

3 things Email Routing can't do

It can't store mail

There's no mailbox. If the destination files a message as spam, Cloudflare doesn't have a copy. The dashboard keeps an Activity log of recent messages and a daily forwarded/dropped count. That's it, unless the rule targets a Worker (next section).

It can't be shared

A rule maps one address to one destination. To copy two people, you already need a Worker calling forward() twice. Then each person has a copy and no idea whether the other one replied.

So the personal-inbox setup breaks the day a second person needs to see support mail.

It can't reply as support@ later

Hit reply in your mailbox, and the answer goes out from your personal address. An Email Worker can call message.reply(), but only once, inside the same SMTP session, and only to the original sender. If a person answers an hour later, you need Email Sending or another provider.

Where an Email Worker gets you

A routing rule can target a Worker instead of "Send to an email". The Worker gets the raw message as a stream and can store it, forward a copy, or reject it:

export default {
  async email(message, env, ctx) {
    const raw = await new Response(message.raw).text();
    await env.DB.prepare("INSERT INTO mail (from_addr, to_addr, raw) VALUES (?,?,?)")
      .bind(message.from, message.to, raw)
      .run();
    await message.forward("you@personal.example");   // destination must be verified
  },
};

That's the whole trick behind an inbox: the Worker is the inbox. It handles messages up to 25 MiB per the Email Routing limits, on the free plan, with no extra bindings.

The 30-line version with a D1 schema, plus three self-hosted inboxes built on it, is in Cloudflare Email Worker inbox: store every message in D1. If you're weighing this against a paid mailbox, see Cloudflare Email Routing vs Google Workspace vs Zoho.

The shared inbox I'm sketching on top of this pattern is a waitlist page today, not a product. The form asks one question: which address you route to: guard.guushu.com/inbox.

Original, with any later corrections: guushu.com/notes/cloudflare-email-routing-support-address/

Cloudflare Email Worker inbox: store every message in D1 in 30 lines

HowardZlh — Mon, 28 Sep 2026 07:14:09 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

Email Routing forwards a message and keeps nothing. If you want a copy you can search later, point the routing rule at a Worker, write the message to D1, and forward it on. That's a Cloudflare Email Worker inbox, about 30 lines of TypeScript.

Three self-hosted projects already ship that shape, two open source and one source-available. Below are the handler, the schema, the wrangler side, and those three projects in case you'd rather clone than write.

One caveat up front: I haven't run this handler in production. My own support@ still forwards straight to a mailbox. The code follows the Email Workers docs and the three projects below, which do run it.

The 3 self-hosted inboxes built on Email Routing

All three take the same route. An Email Worker receives the message, parses it, and writes it to D1 (and R2 for attachments). A small web UI reads it back. I checked licenses and stacks against each repo on 2026-09-16.

Project	License	Stack	Up-front cost
cloudflare/agentic-inbox	Apache-2.0	Workers + D1; built as an inbox that AI agents can read and act on	Free plan is enough to receive; one `wrangler deploy`
HQBase/hqbase	AGPL-3.0	Workers + D1 + R2 + Queues; sends through the Cloudflare `send_email` binding; AI-native team email workspace	Same deploy; R2 and Queues bindings to create
mirza-rizvi/ResolveHQ	Source-available (not open source)	Email Routing + Resend + D1 + R2 + Queues; shared inbox, threading, AI assist	Its README says it runs on Workers Free for small teams; R2 is activated separately, plus Resend DNS records for outbound

Self-hosting any of them means you own the D1 migrations, the R2 bucket, the reply path, and the pager when it breaks. If that's fine and one of them fits, clone it and skip the rest of this note.

Why does Cloudflare Email Routing have no built-in mailbox?

Cloudflare's product is the edge, not storage. Email Routing sits at the MX layer. It accepts the SMTP session, applies your rules, and hands the bytes to a destination. Storing mail would mean retention, search, quotas, abuse handling. The way out is that a destination can be a Worker, and all three projects above take it.

The email() handler

An Email Worker exports an email() method alongside, or instead of, fetch():

import PostalMime from "postal-mime";

export default {
  async email(message: ForwardableEmailMessage, env: Env, ctx: ExecutionContext) {
    const raw = await new Response(message.raw).arrayBuffer();   // full MIME, up to 25 MiB
    const parsed = await PostalMime.parse(raw);

    await env.DB.prepare(
      "INSERT INTO messages (id, from_addr, to_addr, subject, text_body, received_at) VALUES (?,?,?,?,?,?)"
    )
      .bind(
        crypto.randomUUID(),
        message.from,
        message.to,
        parsed.subject ?? "",
        parsed.text ?? "",
        new Date().toISOString()
      )
      .run();

    ctx.waitUntil(message.forward("you@personal.example"));     // must be a verified destination
  },
};

Three things worth knowing before the first deploy.

message.raw is a ReadableStream, not a string. Wrap it in a Response to read it once. A second read comes back empty.

forward() only accepts verified destinations, the same list as the dashboard. An unverified address throws, and the sender gets a bounce. One rule maps to one destination or one Worker, so fan-out to several people means calling forward() once per address.

There's also setReject(reason). If the Worker decides a message is spam, message.setReject("...") ends the SMTP session with a 5xx. Nothing gets stored or forwarded.

The wrangler config and the routing rule

{
  "name": "inbox",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "d1_databases": [{ "binding": "DB", "database_name": "inbox", "database_id": "..." }]
}

Then in the dashboard: Compute, Email Service, Email Routing, your domain, Routing rules, Create routing rule, your address, action Send to a Worker, pick inbox. There's no wrangler command for the rule itself. It's a dashboard click or the REST API.

Renaming the Worker drops the binding. Rename first, then re-point the rule.

The D1 schema

CREATE TABLE messages (
  id TEXT PRIMARY KEY,
  from_addr TEXT NOT NULL,
  to_addr TEXT NOT NULL,
  subject TEXT NOT NULL DEFAULT '',
  text_body TEXT NOT NULL DEFAULT '',
  received_at TEXT NOT NULL
);
CREATE INDEX messages_received ON messages (received_at DESC);

D1's free tier is 5 million rows read and 100,000 rows written a day. A support address getting 100 messages a day uses 0.1% of the write budget.

The index on received_at is what stops "latest 50" from scanning the whole table. Every D1 case in Why Cloudflare bills spike is a missing index.

Push attachments to R2 instead of D1. For text-only support mail, D1 alone is where I'd start.

What you have, and what you don't

You end up with a Worker that works as a mailbox. Every message is saved, searchable with SQL, and still forwarded to your phone.

You don't get a UI, threading, "who's handling this", or a way for a person to reply from support@ an hour later. That's what the three projects at the top add. The setup steps before any of this are in Cloudflare Email Routing support address.

The hosted version of this handler plus a two-person interface is a waitlist page today, not a product. The form asks which address you route: guard.guushu.com/inbox.

Original, with any later corrections: guushu.com/notes/cloudflare-email-worker-inbox-d1/

Cloudflare zone security checklist: 12 read-only checks, one curl each

HowardZlh — Thu, 24 Sep 2026 03:26:50 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

I wrote this Cloudflare zone security checklist after "I'm sure I turned that on" led me to a WAF custom rule blocking curl/* on a zone I never set up that way. Twelve checks, each with a terminal command, so the answer is a number instead of a memory.

By hand it takes about ten minutes per zone. Fine for one zone. The last section is about what happens with more.

Set these once for the shell snippets. The token is read-only (Zone Read, Zone Settings Read, DNS Read, Firewall Read).

export CF_TOKEN=...
export ZONE_ID=...
export ACCOUNT_ID=...
cf() { curl -s -H "Authorization: Bearer $CF_TOKEN" "https://api.cloudflare.com/client/v4$1"; }

TLS: minimum version, Always Use HTTPS, HSTS

1. Minimum TLS 1.2. Anything lower is a compliance finding waiting to happen.

cf /zones/$ZONE_ID/settings/min_tls_version | jq .result.value    # "1.2"

2. Always Use HTTPS. Plain-HTTP requests should 301, not serve content.

curl -sI http://example.com | grep -i location

3. HSTS with max-age of 6 months or more. No header means it's off. The toggle is under SSL/TLS, Edge Certificates.

curl -sI https://example.com | grep -i strict-transport-security

That's how checks 1 and 3 look in the dashboard on my zone. The curl output is the one to trust, since it's what browsers get.

WAF, bots, rate limiting

4. WAF managed rules deployed. The Free plan gets the Cloudflare Free Managed Ruleset, and Pro and up get the full set. Either way it should be deployed, not just available. 0 means nothing is.

cf /zones/$ZONE_ID/rulesets/phases/http_request_firewall_managed/entrypoint | jq '.result.rules | length'

5. Bot Fight Mode on. Security, Bots, one toggle. Turn it off only if you know which integration it breaks, and write that down.

6. Rate limiting on auth and form endpoints. The Free plan includes one rule. Put it on /login, /api/auth or the contact form.

cf /zones/$ZONE_ID/rulesets/phases/http_ratelimit/entrypoint | jq '.result.rules[].description'

DNS: DNSSEC, mail records, orphans

7. DNSSEC enabled. Empty output means the DS record isn't at the registrar, even if Cloudflare shows "pending".

dig +short DS example.com

8. SPF, DKIM, DMARC, even if the zone sends no mail. Especially then. A domain with no mail policy can be spoofed by anyone. Baseline for a non-sending zone is v=spf1 -all and v=DMARC1; p=reject.

dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com

9. No orphaned records. Records pointing at IPs or hosts you no longer control are a subdomain-takeover risk. The check is boring. List everything and ask "what's this?"

cf "/zones/$ZONE_ID/dns_records?per_page=500" | jq -r '.result[] | "\(.type) \(.name) -> \(.content)"'

Access, API tokens, audit log

10. Admin paths behind Access. Think /admin, /wp-admin, internal dashboards. An Access application with an email allow-list is free for up to 50 users.

cf /accounts/$ACCOUNT_ID/access/apps | jq '.result[].domain'

11. Scoped API tokens, not the Global API Key. Automation runs on minimum permissions and an expiry. Tokens with "expires_on": null are the ones to look at.

cf /user/tokens | jq '.result[] | {name, status, expires_on}'

12. Audit log reviewed. Cloudflare keeps one per account and nobody reads it. Once a month, count the changes. If the number surprises you, that's the finding.

# macOS date syntax; on Linux use: date -u -d '30 days ago' +%Y-%m-%dT00:00:00Z
cf "/accounts/$ACCOUNT_ID/audit_logs?since=$(date -u -v-30d +%Y-%m-%dT00:00:00Z)" | jq '.result | length'

Why check Cloudflare zone settings you already set?

Because settings drift and nobody sees it. The curl/* rule above was on my zone before I started this project. It returned 403 to every probe, while browsers got through fine, and so did Workers and webhooks. Every check here is a read-only API call, so a cron can snapshot each zone daily, diff it, and email you only when something changed.

Twelve checks, ten minutes, every zone, every month. For one zone that's a coffee. For forty it's a day, and it's the kind of day that gets skipped. The bill-side version of the same drift problem is in Why Cloudflare bills spike.

The daily version of this list, read-only tokens in, a drift diff out, is a form today, not a product. It asks one question, how many zones you manage: guard.guushu.com/zone-audit.

Original, with any later corrections: guushu.com/notes/cloudflare-zone-security-checklist/

Why Cloudflare bills spike: 8 D1 and Durable Objects cases from 2026

HowardZlh — Wed, 23 Sep 2026 09:24:44 +0000

Originally published at guushu.com/notes. I keep the original updated, so this copy may lag.

Eight public Cloudflare bill spikes turned up in 2026 threads on Cloudflare Community and Hacker News. Seven are D1 rows read. One is a Durable Objects alarm loop.

Every fix was one index or one guard on a re-schedule. The fix was never the hard part. Nobody saw the meter move for days.

What goes in the table: thread title, date, product, amount. No usernames, no quotes, no links to the threads. Amounts are what the poster said, rounded. Where they didn't say, the table says so.

Last checked 2026-09-15. I add rows when I find them and bump the updated date at the top.

The 8 incidents, by product and amount

Date	Source	Product	Amount	What moved
04-16	HN	Durable Objects	about $34,895 over 8 days	Alarm re-scheduled itself in a loop; zero users
06-29	CF Community	D1	about $800	Sitemap of 380,000 pages crawled; every page a full-table read
08-03	CF Community	D1	about $176	Rows read overage on a small site
08-10	CF Community	D1	about $4,115	$5 subscription; D1 rows read ran for a month
08-25	CF Community	Workers / D1	not stated	"Accidentally incurred a large billable usage"
09-01	CF Community	D1	invoice about $1,481, credit asked about $976	1.476 trillion rows read
09-03	CF Community	D1	not stated	Overage after a data migration; backfill loop
09-11	CF Community	D1	quota hit, no invoice yet	Rows read shown as 235k in one view and 11.5M in another

Seven D1, one Durable Objects. The smallest stated amount is $176. The largest is $34,895.

D1 pricing is $0.001 per million rows read. So the 09-01 invoice is just what 1.476 trillion of anything costs on a per-million meter.

Why does D1 bill rows read instead of requests?

D1 meters rows scanned, not queries. A SELECT ... WHERE slug = ? on a table with no index on slug scans the whole table on every request. Take 10,000 rows and 100 requests a minute. After one day that's 1.4 billion rows for one small site, and the query count never moved.

Every D1 row in the table is that meter. The 09-03 migration is the same thing in a different shape: a backfill ran SELECT inside a loop over a table that had just grown.

Durable Objects alarm loops that never sleep

The Durable Objects case is an alarm handler that set the next alarm at the end of every run. Failed runs too.

Durable Objects requests are metered per million on Workers Paid. A loop with no sleep and nobody watching runs until the invoice shows up. Eight days, about $34,895, zero users.

A 10,000x jump that nobody saw for days

None of these are Cloudflare being expensive. In every thread the metric jumped 10,000x or more, and the first sign was the invoice or a quota email.

Cloudflare's Budget alerts arrived in 2026-04 and have been on by default for pay-as-you-go accounts since 2026-07. They send one email at the threshold. The docs call them informational only. They don't pause or cap anything, so someone still has to log in and act.

Where to see D1 rows read and DO requests before the invoice

Dashboard: Storage & databases → D1 SQLite Database → your database → Overview. The "Rows read" chart is per database. You're looking for a flat line that suddenly isn't. Below it, the Queries table ranks statements; sort by Rows read and check the Rows read/returned column.
GraphQL Analytics: dataset d1AnalyticsAdaptiveGroups, dimension databaseId, sum of readQueries and rowsRead over a date range. Same numbers as the dashboard, but you can script it.
Durable Objects: Workers & Pages → Durable Objects → Metrics. Requests and alarm invocations per namespace. One namespace climbing on an otherwise flat account is the loop.

That's my own metrics database, last 30 days. The fourth row is a scan: 71 calls, 965,520 rows read, about 2,770 rows read for every row it returns. It costs nothing at this size. It's the same shape as every D1 row in the table above: a lookup by max(created_at) per source on a table with no index. Two indexes, (source, created_at) and (created_at), fixed it on 2026-09-28.

The total doesn't tell you much. The check worth automating is whether today is more than 10x the last seven days.

How I now guard my own D1 and Durable Objects usage

Every D1 table I query by a non-primary-key column gets an index on that column. New queries go through EXPLAIN QUERY PLAN first, and anything that says SCAN gets an index or a rewrite. My own D1 is about 15,000 rows, and the screenshot above still caught one scan, so it's a habit I'm still enforcing, not a war story. The smallest example is the received_at index in my Cloudflare Email Worker inbox, 30 lines that store mail in D1.
I don't run Durable Objects yet. When I do, the re-schedule goes in the success path only, with a retry counter on the object.
Since 2026-09-15 the "10x the last seven days" check has run on my own account as a small read-only Worker, usage-guard-collector (MIT). Every 6 hours it reads the GraphQL Analytics API into a D1 table and flags any meter that's 10x its 7-day median. The hosted version linked below is still a waitlist page.

What this page can't tell you: eight rows isn't a dataset, the amounts are self-reported, and I only read English-language threads. If you know a public thread that belongs here, the address in the footer works.

I'm building a small watcher for exactly this gap. If a bill has surprised you, the one-question form is at guard.guushu.com.

Original, with any later corrections: guushu.com/notes/cloudflare-bill-incidents-2026/

AI is good! Me, using AI, am good! others, no!!!😅

HowardZlh — Wed, 23 Sep 2026 09:22:02 +0000

Reframes hiring tests as price negotiations

Info Inlet

Sep 22

I interviewed the people who rejected me. Here's what their hiring process is actually optimizing for.

#discuss #ai #career #hiring

6 min read