Test, observe, and operate KV

Monitor usage and recover

Track reads, writes, storage, errors, and key ownership while keeping an authoritative rebuild path for cache data.

A KV namespace in production needs the same care as any datastore. You should know what’s in it, who owns it, how much it costs, and how you would rebuild it.

Start with names. Name namespaces by application and environment, like myapp-config-production and myapp-config-preview, so nobody has to guess what my-namespace-2 holds.

Record who owns the key format and the retention policy. Six months from now, someone will ask whether user:* keys can be deleted. “Ask the person who left” is not an answer.

Watch the numbers that bill you

Reads, writes, deletes, and lists are billed separately, and storage accumulates. Monitor operation volume, storage, latency, and Worker errors against the current limits and pricing.

The dashboard shows per-namespace analytics. Check them against what you expect. A read count ten times your traffic usually means a loop is reading per item instead of once per request.

You can also inspect a namespace directly:

npx wrangler kv key list --binding CONFIG --remote | head
npx wrangler kv key get --binding CONFIG feature-flags --remote

Alert on error rates in the Workers that use the namespace. That’s where KV failures surface.

Keep a rebuild path

If KV is a cache, document how to rebuild it from the source of truth. If it stores configuration, keep the source in version control or keep an export path.

The recovery plan for derived data is not a backup. It’s regeneration:

node scripts/build-config.mjs > config.json
npx wrangler kv bulk put config.json --binding CONFIG --remote
# Success! Uploaded 214 key-value pairs

Here the JSON file lives in git, and the namespace is disposable by design. Losing it costs one command.

Deleting is the dangerous operation

Never delete a shared namespace until you have checked every binding and every deployment. Preview environments, old deployments, and other Workers may still bind it.

The failure shows up in their logs, not where you ran the delete. So you get a report of a broken preview site hours later, and nobody connects it to the cleanup you did in the morning.

Try this: rebuild a disposable practice namespace from a small versioned configuration file with kv bulk put. Then switch a preview binding to the new namespace and verify the application reads from it.

Lesson completed