Error 524: A timeout occurred

error524.png

A 524 error states that CloudFlare was able to make a TCP connection to the origin, but the origin did not reply with a HTTP response before the connection timed out.

Our edge will typically wait for a HTTP response from your server for 100 seconds.

If no response is sent by your server in that time, we close the connection and serve a 524 error page.

This error is commonly caused by a long-running process on the origin server, such as a PHP application or a database query which the web server must wait on before responding to a request.

A 524 can also be caused by your origin server being overloaded- if you see this error it's a good idea to check your server's available resources, including CPU and RAM, and overall traffic levels. If your server has a high CPU load, or is low on memory, this could indicate a resource problem.

If you're unsure about the health of your server it's a good idea to contact your hosting provider and ask them to investigate.

If you regularly run HTTP requests that take over 100 seconds to complete (for example large data exports), one alternative is to move those long-running processes to a subdomain that is not proxied by CloudFlare. That subdomain would have the orange cloud icon toggled to grey in the CloudFlare DNS Settings. Note that you cannot use a Page Rule to avoid a 524 error.

Advanced users: Logging response time at your web server.

If you have access to change your web server configuration files, you can actually log how long your server took to respond to a request by modifying the log format.

Most web servers store the response time as a variable, which means you simply need to add this to your log configuration file.

Apache declares logging format in the LogFormat or CustomLog directives, depending on whether you are changing this globally, or for specific virtualhosts.

Response time is stored as the %T variable. Please see the mod_log_config documentation here:

http://httpd.apache.org/docs/current/mod/mod_log_config.html

For Nginx you can modify the log_format directive. Response time is stored as the $request_time variable:

http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format

Advanced users: Measuring the response time using curl

You can use the cURL utility from Terminal (on Mac OSX and Linux) to measure how long a request takes to respond. cURL has a write-out flag which allows you to print specific information about a request using custom variables.

https://curl.haxx.se/docs/manpage.html

You can use the %{time_connect} and %{time_starttransfer} variables to measure how long it takes to connect to your server, and how long it takes for your origin to return a response (i.e. time to first byte) using the following:

curl -vso /dev/null -w "Connect: %{time_connect} \n TTFB: %{time_starttransfer} \n Total time: %{time_total} \n" http://www.example.com

If you want to test this directly to your origin server you can do this too by sending a request directly to your server IP address and passing in a host header:

curl -vso /dev/null -w "Connect: %{time_connect} \n TTFB: %{time_starttransfer} \n Total time: %{time_total} \n" -H ‘Host: www.example.com’ http://1.2.3.4

At the bottom of these commands you’ll see three fields, similar to the below:

Connect: 0.154

TTFB: 1.734

Total time: 1.734

Connect indicates how long it took to establish a TCP connection to the server. This should generally be a fairly low value.

TTFB will indicate how long it took to generate a response.


If you see the response taking longer than 100 seconds you know this will have triggered a 524 via CloudFlare.

Still not finding what you need?

The CloudFlare team is here to help. 95% of questions can be answered using the search tool, but if you can’t find what you need, submit a support request.