Error 524: A timeout occurred


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.

Railgun Users: A 524 can also manifest if the time specified by lan.timeout is exceeded. This defaults to 30 seconds, so if you're seeing 524 errors with your Railgun enabled, we recommend setting this value higher. 

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:

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

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.

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"

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:’

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.

Powered by Zendesk