HTTP 504s in logs

(@mattquist)

I am successfully running Staatic for a few wordpress sites, and am very happy with it.  I have noticed lines in my apache logs which I assume are triggered by wp-cron, eg:


34.252.113.203 - staatic [06/Jul/2026:09:40:01 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=6d762b7461 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:21:40:02 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=81f4cd122c HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:05:00:05 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=6d762b7461 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:17:00:05 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=81f4cd122c HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:11:20:10 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=6dd2fd2a7e HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:23:20:09 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=698cb18c83 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:03:40:14 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=789582f958 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:15:40:14 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=66c4ebdc71 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:09:20:17 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=568a1d3530 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:21:20:18 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=eefce74eb5 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:12:40:22 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=ea292a8b64 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:09:00:26 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=5862c09600 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:21:00:26 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=7e8423e3e9 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:09:40:30 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=739414a0f8 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:21:40:30 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=68be26c39a HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:07:20:34 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=da240af80c HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:19:20:34 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=a22b010146 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:05:40:38 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=2abce33853 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:17:40:37 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=9e9af2c4c2 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:04:40:42 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=45f2e87e02 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:16:40:42 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=80837dfe83 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:05:20:46 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=f738f776d1 HTTP/1.1" 504 494 "-" "WordPress/7.0;"
34.252.113.203 - staatic [06/Jul/2026:17:20:46 +0100] "POST /wp-admin/admin-ajax.php?action=staatic_test_request&nonce=07cae039e9 HTTP/1.1" 504 494 "-" "WordPress/7.0;"

I wanted to check that these HTTP 504 responses are not causing a problem in any way to Staatic, and assuming the 504s mean a lack of success of the request, would it be possible to stop the request being made in the first place?

Viewing 3 replies - 1 through 3 (of 3 total)

Plugin Support Frank
(@staaticfrank)

2 weeks, 1 day ago

Hi @mattquist , those requests are Staatic’s internal publication test task. It is used by the Site Health checks to determine how long WP-Admin/background publication tasks can run before the server cuts them off.

The request is intentionally long-running: Staatic dispatches a background request to admin-ajax.php?action=staatic_test_request, and the receiving request sleeps in short intervals while updating its status. It is scheduled through WP-Cron, normally twice daily.

A 504 here does not necessarily mean a Staatic publication failed or that your static site output is affected. However, it does indicate that the web server, proxy/gateway, load balancer, or PHP/FastCGI layer is terminating that diagnostic request. If publications are started from WP-Admin, the same kind of timeout limit can also affect longer-running publication tasks.

Could you check Tools > Site Health and see what Staatic reports for the publication task timeout / publication test task? If it reports a low timeout, the next things to check are PHP/webserver/proxy limits such as max_execution_time, PHP-FPM request_terminate_timeout, Apache/Nginx timeout settings, or any load balancer/proxy timeout.

If you have WP-CLI available, publishing with: wp staatic publish can avoid many of the limits that apply to WP-Admin/background requests.

If your publications are working reliably and you only want to disable this diagnostic task, you can add this small site-specific snippet:

add_filter( 'staatic_test_request_enabled', '__return_false' );

That disables the long-running part of the test. You may still see a short admin-ajax.php?action=staatic_test_request request, but it should return quickly instead of running until the server times it out.

I would only recommend disabling it if you understand that it disables this Site Health diagnostic. If you rely on WP-Admin publications, it is usually better to fix the underlying timeout.

Thread Starter mattquist
(@mattquist)

2 weeks, 1 day ago

many thanks for the comprehensive reply – it is very much appreciated

despite the 504s all 4 staatic checks in Site Health report OK:

Permalink structure appears to be configured correctly
Staatic work directory is writable
Publication task timeout appears to be in order
Staatic can perform loopback requests

the server is very modestly spec-ed as it’s for authoring only, so given I’ve seen all tests passed I’ll probably do the suggested:

add_filter( 'staatic_test_request_enabled', '__return_false' );

to keep the load down – I can’t see reason (for me personally) to repeatedly execute a long running php task that’ll consume a php worker when I know it’s going to succeed?

Plugin Support Frank
(@staaticfrank)

2 weeks, 1 day ago

That sounds perfectly reasonable.

If all Staatic Site Health checks pass and publications are completing reliably, disabling that diagnostic task is fine. It only affects the long-running runtime check; it does not disable publishing or crawling.

The only trade-off is that Staatic will no longer keep testing that particular timeout automatically, so if the hosting/proxy configuration changes later, you may want to re-enable it temporarily or run the check again.

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.