Frequent timeouts on Statamic site despite static caching (“half”) — requests hitting PHP instead of cache

[stephenmeehanuk]

I’m seeing lots of 60s PHP-FPM timeouts and recv() failed ... from upstream in NGINX, while responses show cf-cache-status: DYNAMIC and Set-Cookie, implying pages aren’t being served from a pre-baked/static cache. Looking for guidance on why Static Caching (“half”) might be bypassed and how to stop anonymous requests from starting sessions / missing cache.

Context

• Sites: lbfoster.com and skratchtech.com
• Statamic: Pro, STATAMIC_STATIC_CACHING_STRATEGY=half
• PHP: 8.4, FPM
• Web: NGINX (behind Cloudflare)
• Sessions/Cache: Redis (session + queue + cache)
• Debugbar: disabled
• Warmers: queues configured STATAMIC_STATIC_WARM_QUEUE, workers running

Symptoms

Lots of PHP-FPM timeouts

• PHP-FPM slow log shows many requests to public/index.php exceeding 60s and getting terminated.
• Example slowlog frames include Statamic static caching middleware & Laravel sleep/locking (see below).

NGINX upstream read errors

• NGINX error log shows recv() failed (104: Connection reset by peer) while reading response header from upstream, upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock:"

Responses look dynamic (not cached)

• cf-cache-status: DYNAMIC
• Cache-Control: no-cache, private / must-revalidate
• Set-Cookie: XSRF-TOKEN=..., _session=...
• x-powered-by: Statamic
• These headers + cookies suggest the requests are processed dynamically and also won’t cache at the edge.

What I’ve tried

NGINX fastcgi timeouts (per site):

fastcgi_connect_timeout 60s;
fastcgi_send_timeout    60s;
fastcgi_read_timeout    65s;

PHP-FPM pool tweaks:

pm = dynamic
pm.max_children = 50
pm.start_servers = 6
pm.min_spare_servers = 6
pm.max_spare_servers = 12
pm.max_requests = 500
request_slowlog_timeout = 3s
request_terminate_timeout = 60

• memory_limit lowered to 256M (from 1024M).
• Bot/scanner blocks added at NGINX
• Verified workers and Redis are up; queues running.

Despite this, during traffic bursts many requests still time out and logs show PHP generating pages.

Logs

NGINX error log (fastcgi upstream)

recv() failed (104: Connection reset by peer) while reading response header from upstream,
client: <ip>, server: lbfoster.com,
request: "GET /some/page HTTP/2.0",
upstream: "fastcgi://unix:/run/php/php8.4-fpm.sock:",
host: "lbfoster.com"

PHP-FPM slow log (Statamic stack & locking)

[pool www] ... script '/home/ploi/lbfoster.com/public/index.php' ... execution timed out (60.x sec), terminating

... /vendor/laravel/framework/src/Illuminate/Support/Sleep.php:351 usleep()
... /vendor/laravel/framework/src/Illuminate/Cache/Lock.php:125 block()
... /vendor/statamic/cms/src/StaticCaching/Middleware/Cache.php:59 handle()
... /vendor/statamic/cms/src/Http/Middleware/StacheLock.php:29 handle()
... /vendor/symfony/yaml/Parser.php ... (YAML parsing stack)

This looks like requests are waiting on locks (static cache generation?) and doing heavy template/YAML work instead of serving a pre-rendered page.

Response headers (dynamic)

HTTP/2 200
cf-cache-status: DYNAMIC
cache-control: no-cache, private (or max-age=0, must-revalidate, no-cache, no-store, private)
set-cookie: XSRF-TOKEN=... ; <app>_session=...
x-powered-by: Statamic

###Questions

Are there any known conditions that disable/bypass static caching (“half” strategy) for anonymous GET/HEAD?

Lock contention during cache generation?

• The slowlog shows Sleep::goodnight()/Cache::block() around StaticCaching\Middleware\Cache.
• Could high concurrency be dog-piling on uncached pages, causing lock waits → timeouts?
• Any recommended settings to tune Statamic’s static cache locking/backoff?

Warmers

• With STATAMIC_STATIC_WARM_QUEUE set: anything else required to ensure the warmer fully primes all commonly hit routes?
• Is there guidance on verifying “coverage” (what’s actually warmed vs still cold)?

###Env details

• PHP-FPM avg child RSS: ~146 MB (20 procs; ~2.9 GB total) on a 16 GB box
• Timeouts: FPM request_terminate_timeout=60; NGINX fastcgi read 65s
• Statamic: Pro, STATAMIC_STATIC_CACHING_STRATEGY=half
• Sessions/Queue/Cache: Redis
• Cloudflare: in front; seeing cf-cache-status: DYNAMIC on pages

Happy to provide template snippets (layouts/partials), and any specific config you want to see.

Thanks in advance for any pointers!

[stephenmeehanuk]

Hmmm. Looks like this is related to Weglot (which uses Cloudflare).

When I cURL a cached asset, it still outputs cf-cache-status: DYNAMIC

curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
     https://abc.com/build/assets/site-D_m2tu_P.css

HTTP/2 200 
date: Wed, 17 Sep 2025 20:05:00 GMT
content-type: text/css
server: cloudflare
cf-ray: 980b37421a4db13e-MAN
cf-cache-status: DYNAMIC
cache-control: max-age=604800, public, max-age=604800
etag: W/"684c389c-35c44"
expires: Wed, 24 Sep 2025 20:05:00 GMT
last-modified: Fri, 13 Jun 2025 14:41:32 GMT
vary: Accept-Encoding
processed-by: Weglot
weglot: id.980b37421a4db13e, p.cf, cs
weglot-translated: false - original

I've got a cache policy of 7 days for CSS (and other assets).

Cloudflare Ignores It: Treats as dynamic anyway

Weglot is processing every single request - even CSS files - and marking them as dynamic content. This forces Cloudflare to bypass its edge cache completely. No edge caching = Every request hits your PHP-FPM.