DEV Community: Escrozon

Cloudflare cached our 404s: why a new page kept 404ing after a good deploy

Escrozon — Sat, 26 Sep 2026 18:02:43 +0000

We run Escrozon, an escrow marketplace for digital assets, behind Cloudflare. A while ago we shipped a new landing page. The deploy went fine and the server returned the page, but visitors kept getting a 404 for almost an hour.

Nothing was wrong with the deploy. Cloudflare had cached the 404, and we had caused it ourselves by asking for the page before it existed.

What happened

Before the deploy, we checked whether the new URL was already live. It returned 404, which was correct at that moment.
Our Cloudflare cache rule keeps HTML at the edge for an hour (s-maxage=3600), and it applied to that 404 as well.
The deploy finished and the origin served the page with a 200. Cloudflare kept serving its stored 404 until that copy expired.

It can also look inconsistent. Unless Tiered Cache is on, each Cloudflare data center keeps its own copy, so visitors in one region may see the page while others still get the 404.

How to tell a stale cached 404 from a broken deploy

Start with the response headers:

curl -sI https://example.com/new-page | grep -iE '^(HTTP|cf-cache-status|age|cache-control)'
# HTTP/2 404
# cf-cache-status: HIT
# age: 2140
# cache-control: public, max-age=14400, s-maxage=3600, stale-while-revalidate=86400

cf-cache-status: HIT means Cloudflare answered from its cache without asking your server.
age is how many seconds that copy has been stored.
s-maxage=3600 is how long the edge may keep it.

This 404 would stay for another 3600 − 2140 = 1460 seconds, about 24 minutes.

Next, skip the cached copy by adding a query string. Cloudflare treats it as a different URL:

curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/new-page?cb=1"
# 200

A 200 with the query string and a 404 without it means the deploy worked. Only the cached copy is stale.

Fixing it right now

You have three options:

Purge that URL. In the Cloudflare dashboard, go to Caching → Configuration → Custom Purge and enter the exact URL. "Purge Everything" also works, but it empties the whole cache.
Purge through the API, which is handy in a deploy script:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
 -H "Authorization: Bearer $CF_API_TOKEN" \
 -H "Content-Type: application/json" \
 --data '{"files":["https://example.com/new-page"]}'

Wait until s-maxage minus age runs out.

Stopping it from happening again

1. Don't request a public URL before it exists. Test on localhost, or directly against your origin server, until the deploy is done. One curl to the public URL is enough to cache the 404.

2. Give 404s a short cache time. Cloudflare Cache Rules let you set an edge TTL per status code. Set 404 (or the whole 4xx range) to no cache, or a few seconds, while pages that work keep their longer TTL.

3. Purge in your deploy script. Call the purge API for the URLs you just shipped, or for everything if the deploy changes shared assets.

4. Know which setting wins. Our app sent s-maxage=300, but the edge served s-maxage=3600 because a Cloudflare rule overrode the origin. Changing the headers in our Next.js config did nothing, because the rule in the dashboard decides.

5. Check Browser Cache TTL. That Cloudflare setting can override the max-age your origin sends to browsers. Ours was 4 hours, so returning visitors saw old pages long after a deploy. Setting it to "Respect Existing Headers" put our origin back in charge.

Measuring cache performance without fooling yourself

Two traps caught us when we tried to measure how fast the cache was:

A cache-busting query string always forces a MISS. It adds a full trip to your origin, so timings measured with it look worse than what real visitors get.
A quick curl -I warms the cache. The next request then looks like a HIT. Measure the status and the timing in the same request:

curl -s -o /dev/null -D /tmp/headers.txt -w '%{http_code} %{time_total}s\n' https://example.com/page
grep -i cf-cache-status /tmp/headers.txt

If your origin is far from many of your visitors, also look at Cloudflare's Tiered Cache. Without it, every Cloudflare location fetches from your origin separately, so the first visitor in each region pays the full trip.

Checklist

cf-cache-status and age tell you whether you're looking at a cached response
A ?cb=1 request shows what your origin serves right now
Purge the URLs you ship, as part of the deploy
404s get no cache, or a very short one, in your cache rules
Nobody requests public URLs for pages that aren't deployed yet
You know whether your origin headers or your Cloudflare rules set the TTL
Browser Cache TTL is set to "Respect Existing Headers"

Caching 404s isn't a bug in Cloudflare. It does exactly what the rules say. The fix is making sure the rules say what you meant.

This post was written with AI assistance, based on our own incident notes and the commands we ran in production.

SQLite in production with Prisma and pm2: how we fixed "database is locked"

Escrozon — Sat, 26 Sep 2026 14:47:56 +0000

We run Escrozon, an escrow marketplace for digital assets, on Next.js with Prisma and a single SQLite file. SQLite suits a small production app well: one file, no database server to look after, and fast reads. But for a few weeks we saw failures that looked random. Some requests died with a Prisma timeout, and our nightly backup job kept failing with database is locked.

They weren't random. Three settings were working against each other. Here's what we found and exactly how we fixed it.

The symptoms

Occasional 500 errors on ordinary pages, more often when several people were active at once
Prisma errors saying the operation timed out while waiting for the database
The nightly backup script stopping with Error: database is locked

The backup script was written to abort instead of saving a broken copy, which was the right call. But it also meant new backups had quietly stopped being made.

Cause 1: the default rollback journal

Check which journal mode your database uses:

sqlite3 db/app.db "PRAGMA journal_mode;"
# delete

delete is SQLite's default rollback-journal mode. In this mode a write needs an exclusive lock on the database file to commit, and readers have to wait until it finishes. A web app reads on almost every request, so those waits pile up. Once a wait is longer than Prisma's timeout, the request fails.

Switch to write-ahead logging (WAL):

sqlite3 db/app.db "PRAGMA journal_mode=WAL;"
# wal

In WAL mode, reads and writes don't block each other. There is still only one writer at a time, but readers keep working while it writes. The setting is saved inside the database file, so you run it once. (There's one exception, covered under restores below.)

Cause 2: two copies of the app writing to the same file

pm2 list looked normal at a glance. pm2 jlist told a different story:

pm2 jlist | jq -r '.[] | "\(.pm_id) \(.name) \(.pm2_env.status)"'
# 5 web online
# 7 web online

Two processes with the same name were running the same server and writing to the same SQLite file. Our ecosystem.config.js declares one app. The second was left over from an old manual pm2 start, and a pm2 save had made it come back after every reboot.

SQLite allows one writer at a time, so a second process only adds lock contention.

pm2 delete 7
pm2 save   # without this, the duplicate returns on the next reboot

Cause 3: Prisma's connection pool

Prisma opens a pool of several connections by default. With SQLite, extra connections in the same process just queue behind the same file lock. We limited the pool to one connection and gave queries a clear lock timeout:

DATABASE_URL="file:./db/app.db?connection_limit=1&socket_timeout=10"

socket_timeout=10 lets a query wait up to 10 seconds for the lock before it fails, instead of failing almost at once.

The result

We fired 24 concurrent writes through Prisma. All 24 succeeded, none hit a lock, and the whole run took about 50 ms. The backup job started working again, and the random 500s stopped.

Here's a small script to run the same test on your own setup:

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

// Use a table where test rows are harmless, and delete them afterwards.
const results = await Promise.allSettled(
 Array.from({ length: 24 }, (_, i) =>
   prisma.auditLog.create({ data: { action: `lock-test-${i}` } })
 )
);

const failed = results.filter((r) => r.status === "rejected").length;
console.log({ ok: results.length - failed, failed });

Four gotchas that cost us time

1. pm2's ecosystem file wins over .env. pm2 injects the env block from ecosystem.config.js, and Next.js doesn't overwrite a variable that is already set. Changing only .env did nothing. We had to change the ecosystem file too, plus the .env inside .next/standalone, because a standalone build carries its own copy.

2. pm2 reload web --update-env doesn't re-read the ecosystem file. It reuses the environment pm2 already stored. This picks up the new value:

pm2 reload ecosystem.config.js --only web --update-env
pm2 save

3. The sqlite3 CLI reports its own settings, not your app's. PRAGMA busy_timeout in the CLI shows the CLI's connection (0). It tells you nothing about what Prisma uses.

4. A typo in the database path creates a new, empty database. Running sqlite3 against a file that doesn't exist silently creates it and reports the defaults. We briefly "found" a regression that was really a wrong filename. Check the path with ls first.

Backups and restores in WAL mode

WAL mode adds two files next to the database: app.db-wal and app.db-shm. Copying only app.db while the app is running can give you an incomplete backup. Use SQLite's own backup command, which is safe in WAL mode, and check the copy:

sqlite3 db/app.db ".backup 'backups/app-$(date +%F).db'"
sqlite3 "backups/app-$(date +%F).db" "PRAGMA integrity_check;"
# ok

If you ever restore an older snapshot, check the journal mode again. A copy taken before the switch is still in delete mode.

Checklist

PRAGMA journal_mode; returns wal
Only one process writes to the database file (check pm2 jlist, not only pm2 list)
connection_limit=1 is set in DATABASE_URL
The new DATABASE_URL is in every place pm2 and Next.js read it from
Backups use .backup and pass PRAGMA integrity_check
The journal mode is checked again after any restore

Set up this way, SQLite handles far more production traffic than people expect. Almost all of our "database is locked" errors came from our configuration, not from SQLite itself.

This post was written with AI assistance, based on our own incident notes and the commands we ran in production.