Access Logs and Common Errors
HTTP response codes are returned by the server to indicate how a request was received. The first digit of the error code indicates the class of the error. For example; a 2xx response is a success response, a 3xx response is a redirect response, a 4xx indicates client error, and a 5xx request indicates a server error. Correctly identifying the response code an asset is returning may be crucial to a swift and easy resolve.
NOTE
Looking for Apache or PHP error logs instead? See our Error Log guide here.
Access Logs
Locating your site’s access logs can be helpful for diagnosing errors or traffic issues. Within the logs you can locate the specific request and the response or error code returned by the server. A search can be run for a timestamp, a URL or an IP address, or the logs can be filtered by type. Finally, logs can be downloaded as a CSV for use in external tools.
A website’s access logs can be found in two locations:
- Log in to the User Portal
- Select the environment name
- In the secondary menu, click Logs
- At the top, select Access
NOTE
Logs are shown in UTC by default. Time zone can be adjusted in Profile & Settings.
Filters
- Severity:
- Need Attention: Items will qualify as Need attention if their status is 301, 401 and/or if.
- Log Type: It will either show NGINX or PHP.
- NGINX
- PHP
- Status: If there is a problem it will show any of the below status codes.
- 400
- 401
- 403
- 404
- Time: This is how far back you can filter the logs to show:
- Last 5 minutes
- Last 30 minutes
- Last 4 hours
- Last 2 days
Log Details
- Sitename: The selected environment (PROD/STAGING/DEV)
- Site URL: Site url (The selected domain)
- Log type: Is it an NGINX or PHP error?
- Severity: Does this need attention? For example, Needs attention
- Domain: Domain name
- Time: The time it was logged
- Verb: Type of request (GET)
- Resource: Where it occurred
- Protocol: HTTP/1/1
- Status: The status code value
- Size: The size of the file
- Referrer: The referrer value
- User Agent: The user agent value
Raw access logs logs files can also be located in the WordPress® admin dashboard.1
- Log in to your WordPress dashboard (wp-admin)
- Click on the WP Engine tab in the main menu to access our plugin
- Select Information
- Scroll down to the Access and Error log section
- Click the link to download the desired access log
403 — Forbidden
The gist of the error is simple – accessing the file or location (or the site itself) is forbidden by a directive on the site. There are a few ways the request may be getting blocked:
- File Permissions
- The page you are attempting to access may have the incorrect permissions. Reset default permissions with this guide.
- File Type
- Certain files our server will not allow to be loaded in your browser, such as the
wp-config.php
file. - Other files that cannot be opened in your browser include files located in a directory that does not include an
index.php
file which allows those files to be viewed.
- Certain files our server will not allow to be loaded in your browser, such as the
- Security Plugin
- Are you using a security plugin on your site? Disable plugins from the database without accessing the wp-admin dashboard.
- Security Plugins
- Are you using a third-party firewall like Sucuri or Cloudflare?
- Temporarily disabling the firewall can confirm if it is causing the error.
- Check your firewall settings and purge any firewall cache.
- WP Engine Security
- It’s possible the WP Engine firewall has blocked your IP, or any rules added to the firewall by request may be inadvertently blocking your activity.
- Try loading the site on another network, such as your mobile device disconnected from WiFi. If the site loads without a 403, contact WP Engine Support with your IP address.
Check out our full 403 and permissions guide here.
404 — Not Found
This error means the asset cannot be found.
The first step to properly assess a 404 error is to determine which kind you are receiving: WP Engine 404, WordPress 404, or Nginx 404.
WP Engine 404
If the 404 page is branded with WP Engine’s information, there are a few possible causes:
- DNS is pointed to WP Engine, but the domain is not properly connected to an environment. Add the domain to the User Portal to resolve this error.
- DNS is pointed to WP Engine, but to the incorrect environment. Ensure you are using the correct IP or CNAME for the intended environment. Learn how to find your DNS Details here.
- If the environment is brand new, it may still be getting set up. Please allow a few minutes for the process to complete.
WordPress 404 Error
Notice that the WordPress theme is still loading. This error usually shows when a page that can’t be found in the database is requested. Resolving this error is likely going to take place within WordPress.
If WordPress is throwing the 404 error:
- Verify the page/post/WordPress element actually exists by locating it in your WordPress admin dashboard or the database
- Verify the page/post/WordPress element is set as public, published or otherwise in a visible state
- Reset permalinks
Subsites in a new Multisite network:
- Occasionally you may encounter an issue with subdirectory multisite installations where subsites will receive 404 errors on assets that should exist in the site’s files.
- For example, you might see 404s on assets like
domain.com/subsite/wp-content/uploads/2019/10/image.jpg
- Your multisite may not have been created properly, reach out to Support for assistance.
Nginx 404 Error
Notice this version shows the default Nginx 404 response page instead. This is the page that shows up when a static file which doesn’t exist is requested.
Nginx serves static assets, which is why a Nginx 404 specifically means an issue with reading or locating the file at the path in your browser.
If Nginx is throwing the 404 error:
- Search the site’s media directories for the file in question.
- If the file exists, it must be:
- Located in the directory path matching the URL in your browser
- Spelled the same in the browser and on the server
- Using the same uppercase and lowercase characters, as static file names are case-sensitive
- If the file doesn’t exist:
- The file needs to be uploaded or relocated to the correct directory
- If the file exists, it must be:
405 — Method Not Allowed
Unlike a 404 error where the file isn’t found, a 405 error says the file is there but the method of request isn’t allowed. This error most commonly returned when your code is interacting incorrectly with WordPress functionality.
As this is most likely an issue with WordPress code (such as a plugin or theme), follow along with our general troubleshooting guide.
413 — Request Entity Too Large
HTTP Response Code 413 occurs when a request (most typically an upload) exceeds the max body size allowed by the server. Large files should be uploaded via SFTP or SSH Gateway.
To learn more about increasing the max file upload size, see this guide.
429 — Too Many Requests
If you receive a 429 error it may be concerning, but this is actually a sign that our security system is working. This error means you’ve exceeded the maximum number of requests to a page within the last second.
If you receive this error in your browser when working, reach out to our Support team to investigate and remove the block if necessary.
Cases where the error is recurring will most likely be due to an automated process, so add a “sleep” or space out crons to resolve.
NOTE: To protect the integrity of our security system, we cannot share the exact limit of requests per second that will generate this error.
444 — Connection Closed Without A Response
A 444 is similar to a 403, in that the request could be blocked by our server configuration. This differs from a 403 in that NGINX closes the connection without actually returning a FORBIDDEN
response. In the browser this will typically display a 502, but in WP Engine access logs it will show a 444. The main distinction other than what is displayed to the visitor is that 444 status codes are excluded from WP Engine’s Billing calculations.
A 444 often means that your site has an Nginx rule in place to block traffic and that it is working.
If you’re specifically receiving a 444 on a login page, this is likely due to a conflict with WP Engine’s login protection security feature. In the browser you may see a 502 on the login page, however the logs will show the 444 error.
The solution is to modify the custom login page code to generate the login URL the same way that WordPress does. Here’s what WordPress uses in the wp-login.php
file:
<form name="loginform" id="loginform" action="<?php echo esc_url( site_url( 'wp-login.php', 'login_post' ) ); ?>" method="post">
The most important part of the code from wp-login.php
file is this portion:
site_url( 'wp-login.php', 'login_post' )
Alternatively, when viewing the login page environment.wpengine.com/wp-login.php, we expect the loginform
action url to have a parameter wpe-login
.
This parameter is added to this url via our mu-plugin. A filter is added, wpe_filter_site_url
, which will add the wpe-login
parameter to the URL string.
500 — Internal Server Error
A 500 error occurs when PHP cannot render properly. These errors are primarily caused by three different issues:
PHP Fatal or PHP Syntax Error
- Review your Site Error logs and look for timestamps around the time the error occurred for PHP
fatal
,syntax
orparse
. - The error will point to a file and a line number that should be reviewed by a developer.
- If you’re unable to resolve the issue, disabling the offending plugin or theme may resolve the error as well.
PHP Parse error: syntax error, unexpected T_STRING in /nas/wp/www/cluster-1234/somewebsite/wp-content/themes/rainbows/functions.php on line 4
In this error we can see there is a PHP parse error in the rainbows theme within the functions.php
file on line 4. Reviewing this file and line will be your next step.
Segmentation Fault
- Segmentation faults can be tricky to diagnose. The cause of this error is a process trying to steal memory allocated to a different process, essentially bad or poorly implemented code.
- If you would like to confirm if the error is a seg fault, you can reach out to our Support team to check the logs.
- To resolve the issue, disable plugins and change the theme one at a time.
502 — Bad Gateway
A 502 error refers to a broken connection (or “gateway”) between two servers. At WP Engine, this usually refers to the connection of NGINX and PHP. This is most commonly caused by just two things:
- The request was killed by the PHP long process killer.
- PHP is not available to return a response to NGINX.
- This can be bad code that PHP failed to process, or an issue with the server itself.
Review our guide to diagnose and troubleshoot a 502 Bad Gateway.
Unlike most other errors, a 503 is unfortunately much more vague. Typically, this is caused by faulty code but it may also be caused by an overloaded server. In many cases it may simply resolve itself after a brief period of time.
- Check your DNS
- A 503 error is not common on WP Engine, so we highly suggest verifying that your DNS is pointed to us properly. A 503 may indicate maintenance on other hosts.
- The 503 may be coming from an intermediate service as well, such as a DNS-level firewall. Try temporarily disabling any third-party firewalls.
- Disable PHP scripts
- If the issue is still not resolved, reach out to our support team for additional assistance.
504 — Gateway Timeout
A 504 error on WP Engine occurs for a very specific reason and due to this will only impact uncached requests. We use a complex queueing system to help ensure each site can serve the maximum number of requests quickly and as fairly as possible. A 504 occurs when this queueing system, and its backlog are both full.
This error helps identify one of the many things that makes WP Engine special. We do not charge you based on PHP workers or limit your available processing resources simply because of what you can pay. Each website on a shared server has the same balanced access to a servers resources. Other hosts will try to sell you PHP workers to get more money from you, but we believe even the lowest priced package deserves enterprise-grade performance.
There are systems in place to prevent 504s from occurring, but if you do see these errors it may be best to reach out to our Support directly for help resolving it.
If your site is not the culprit, we will follow up with the offender to resolve the issue. (Keep your Technical Contact up to date!)
If your site is the culprit, we’ll work with you to identify the cause of the traffic and suggest some possible solutions based on the cause:
- Too many uncached requests to the server
- Support can review any cache-exclusions added to your site for issues. Some custom cache exclusions may need to be removed.
- Excess admin-ajax calls are a common culprit and can be identified in your access logs.
- Update or replace offending plugins/themes. In some cases, you may need to reach out to the Author of the asset.
- Work with a developer to perform the same functions using cached methods.
- Long running uncached requests
- Check your error logs for 502 errors, as these can identify killed processes and would indicate there are processes running too long and becoming backed up, which in turn overburdens the request queue.
- Update or replace offending plugins/themes. In some cases, you may need to reach out to the Author of the asset.
- Optimize your database to help calls complete faster.
- Work with a developer to offload, optimize or break down the functionality so it completes more quickly.
- Upgrade
- If you’ve simply outgrown a shared environment and/or your traffic in the previous two ways cannot be improved, it may be time to upgrade to a Premium plan. A Premium plan means that only your websites have access to a servers resources
- If you are already on a Premium account, it may be time to move to a larger server. A larger server will offer more resources for additional growth and the traffic increases that brings.
- If you’re experiencing increased traffic and 504s from a sale or seasonality, a temporary upgrade can be considered as well. We do not require annual purchases for Premium plans.
For more information see our guide on diagnosing and resolving 504 errors.
520-530 — Cloudflare Error Codes
If you’re using Cloudflare, it’s possible for their servers to create or intercept errors. This can dilute or otherwise confuse the meaning and make an issue more difficult to resolve.
All HTTP statuses between 520 and 530 are Cloudflare-specific codes with unique meanings.
NOTE: If you are troubleshooting GES, refer to this guide instead.
520 – A Catch-All “something went wrong”
- Request included more than 14KB of headers
- Request didn’t include any headers at all
- Empty response (444) from the origin server
- Connection was reset after validating TCP handshake
521 – Blocked by Firewall
- This should never happen on WP Engine servers because we read the X-Forwarded-For headers for all Cloudflare IP addresses.
- 521 means the request was blocked by another firewall that wasn’t WP Engine.
522 – Cloudflare IP Rate Limited
- There has been some kind of a connection reset after the initial TCP handshake, or that the Cloudflare IP has been rate limited.
- We do not rate limit Cloudflare IPs, this error should not present itself due to WP Engine servers.
523 – Null-Routed Origin IP
- This error only shows if the network path to the origin server is unavailable. This could happen if the origin servers IP is null-routed.
524 – Timeout Between Cloudflare and Origin
- The most common error status from Cloudflare, as this is their long-process timeout.
- Cloudflare will wait 100 seconds for a response from the origin server before invoking the timeout. WP Engine has a 60 second timeout on our own servers, so Cloudflare timeout isn’t a common scenario.
- This could be encountered on long requests like CSV imports, long running cron jobs, etc as these are subject to longer timeouts.
525 & 526 – SSL-Related Errors
- 526 specifically means the origin server (WP Engine) does not have a valid certificate. 525 generally means a more complex issue, like a cipher mismatch or lack of SNI.
- This should not be an issue on WP Engine due to the nature of our encryption.
527 – Railgun-specific error
- This error indicates a communication error or timeout error between the sender and listener services powering Railgun.
- WP Engine does not support Railgun.
Mix of 52x errors
If you encounter 522/524/521 errors all mixed together, this typically indicates something is wrong at the origin. If there is actually an issue with a Cloudflare edge node, the error message will indicate an issue with Cloudflare rather than the origin server.
“Are you sure you want to do this? Please try again.”
Most commonly this error comes from a plugin or theme issue. To diagnose this you will need to copy to a Staging/Development site and disable plugins and themes one by one.
If you cannot access your site, learn how to disable plugins from the database.
Error establishing database connection
For WordPress to successfully connect to a database, the following information is needed:
- Database Name
- Database Username
- Database Password
- Database Server
This information is saved in the wp-config.php
file of a WordPress site. If any information is incorrect or unreadable you will receive an error. This information is generated by WP Engine to keep it secure, so it cannot be successfully changed otherwise.
To correct this issue you will need a functioning wp-config.php
file with the correct database information. The easiest way to locate this is to refer to a backup.
Revert to a previous checkpoint, or download a checkpoint and restore the wp-config.php
manually over SFTP.
If you continue to have issues, reach out to WP Engine Support to generate and sync new database credentials.
Allowed memory size of xxx bytes exhausted
This Fatal PHP error indicates that your website needs more memory allocated to WordPress.
Learn how to increase your WordPress memory here.
The maximum value WordPress memory can be set to is 512M. If you’ve increased memory to this point and still receive the error, try copying to a Staging/Development environment and disabling plugins and themes one at a time.
“Upload: Failed to write file to disk”
There are several variations to this error message; “WordPress failed to write to disk“, “WordPress has failed to upload due to an error failed to write file to disk“, and “Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?“.
Each of these messages indicates that the file permissions are not correct and as such the file wasn’t uploaded correctly.
Learn how to reset file permissions here.
If you’ve reset file permissions and are still having issues, confirm that the directory you’re attempting to upload to exists and is accessible using SFTP. Try changing to a different accessible directory.
XML Parsing Errors
These errors you will typically see when working with RSS feeds; “XML Parsing Error: XML or text declaration not at start of entity” or “Warning: Cannot modify header information – headers already sent by …“.
As this is a parse error, the issue will very likely be within some PHP code. Did you modify a theme file recently? An extra space at the end of a file or a tag not being closed are enough to cause this error.
If you’re not sure which files were modified recently in order to revert those manually, try restoring the website to a previous version.
Depending on your RSS feed plugin, you may also check within the plugin settings for a “Fix RSS Feed” option.
Missing or Incorrect DNS
If a site appears down due to “DNS_PROBE_FINISHED_NXDOMAIN” or “ERR_CONNECTION_REFUSED” this is usually stemming from a missing or incorrect DNS record. Any number of things can cause this such as accidental DNS record deletion, the registrar parked the domain without your knowledge, etc.
In order for the site to load the DNS record(s) need to be pointed to the correct WP Engine IP address or CNAME for the environment. You can quickly view the IP address or CNAME record that the domain is pointed to using a DNS checker, like the one: https://www.whatsmydns.net/. Log in to your DNS provider to update the records.
- If the record is missing at your DNS provider, add a new DNS record and point it to the correct WP Engine IP address or CNAME. Once it propagates, the site will load.
- If the record is pointed to the wrong IP (or parked) at your DNS provider, either remove or modify the record to point it to the correct WP Engine IP or CNAME. Once it propagates, the site will load.
Learn how to find your DNS record values and point DNS to WP Engine here.
WordPress Error Notification Emails
As of WordPress version 5.2, you may be notified via email when WordPress detects an error on the website that causes it not to load. A legitimate WordPress automated email will come from wordpress@yourdomain.com
A unique error message will be displayed in the “Error details” section of this email. The guides provided in this article can be used to further shed light on any issues WordPress has detected.
Howdy! Since WordPress 5.2 there is a built-in feature that detects when a plugin or theme causes a fatal error on your site, and notifies you with this automated email. In this case, WordPress caught an error with one of your plugins, [plugin name(s) here]. First, visit your website (http://yourenvironment.wpengine.com/) and check for any visible issues. Next, visit the page where the error was caught (http://yourenvironment.wpengine.com/wp-admin/plugins.php?activate=true&plugin_status=all&paged=1&s=) and check for any visible issues. Please contact your host for assistance with investigating this issue further. If your site appears broken and you can't access your dashboard normally, WordPress now has a special "recovery mode". This lets you safely login to your dashboard and investigate further. https://yourenvironment.wpengine.com/wp-login.php?action=enter_recovery_mode&rm_token=[some-unique-token] To keep your site safe, this link will expire in 1 day. Don't worry about that, though: a new link will be emailed to you if the error occurs again after it expires. When seeking help with this issue, you may be asked for some of the following information: WordPress version (number) Current theme: Theme name (version number) Current plugin: Plugin name (version number) PHP version (number) Error Details ============= An error of type E_COMPILE_ERROR was caused in line 108 of the file /nas/content/live/environmentname/wp-content/plugins/some-plugin/plugin-file.php. Error message: require(): Failed opening required '/nas/content/live/environmentname/wp-content/plugins/some-plugin/includes/modules/loader.php' (include_path='.:/usr/share/pear/php:/usr/share/php')
For more information on this feature, see the WordPress Codex.
Requires the ionCube PHP Loader
Errors related to ionCube may state either PHP Fatal error: [ionCube Loader]
or Requires the ionCube PHP Loader
. These errors refer to the ionCube Loader module, which is disabled for performance reasons across WP Engine.
Updating the plugin or theme may resolve the issue, otherwise an alternative will need to be found.
For more information on disabled modules, see our Platform Settings guide.
NEXT STEP: Learn about the site error log