Why the log window matters more than the log viewer
When a student writes in on Monday to say a checkout failed on Friday night, the evidence may already be gone. Kinsta's server logs documentation says log files are retained for up to 4 days and cannot be manually cleared. WP Engine's error log table covers up to 1,500 errors from the last 48 hours. SiteGround's live Access Log view shows only the latest 300 entries for the current day, although older days are archived up to 30 days back.
Two logs answer different questions. The access log shows that a request arrived, which URL it hit, and the HTTP status the server returned. The error log shows why PHP failed, for example a fatal error in a payment or membership plugin. A 500 status in the access log at 18:05:12 is only useful if you can match it to an error log entry from the same second.
The practical rule: download the relevant day's logs as soon as a payment or login problem is reported, and keep them outside the host. A screenshot of a dashboard filter is not enough once the window has passed.
Where each host keeps logs
Locations and windows below are taken from each host's documentation. Window means what the documentation says you can see or download, not a guarantee that older data is unrecoverable through support.
| Host | Where to look | Logs available | Window | How to download |
|---|---|---|---|---|
| Kinsta | MyKinsta > Sites > your site > Logs | error.log (includes PHP errors), access.log (Nginx requests), kinsta-cache-perf.log (cache hit, miss or bypass); cache-purge.log and mail.log through SFTP only | Retained up to 4 days | Files > root directory > logs folder > Download, or SFTP to the logs folder |
| WP Engine | User Portal > environment > Logs (under Advanced), Error or Access tab; also wp-admin > WP Engine > Information | PHP error log; origin access log (traffic that reached the WP Engine server); edge access log (traffic that reached Cloudflare) | Errors: up to 1,500 from the last 48 hours. Origin: most recent 1,500 requests. Edge: up to 20 million requests from the past 72 hours | Download from the Logs page; edge download links expire after 24 hours and a new file can be generated every 5 minutes |
| SiteGround | Site Tools > Statistics > Error Log or Access Log | Error log; access log with IP, timestamp, request type, URI, status, referrer and user agent | Access Log view: latest 300 entries for today. Archived raw access logs: up to 30 days back | Error Log: Copy to clipboard. Archived access logs: /home/username/www/domain.com/logs through File Manager, FTP or SSH |
| DigitalOcean WordPress 1-Click Droplet | On the server over SSH | Caddy web server logs read with journalctl -u caddy; PHP-FPM service status with systemctl status php8.3-fpm | Set by your server configuration | You copy files off the server yourself |
Host-by-host details that trip people up
Kinsta: the file without a date suffix holds the current day. Older files are named with the date of the following day, so a file dated 24 July holds the previous day's entries, up to just after midnight on 24 July. If you turn on WordPress debugging from MyKinsta Tools, errors are captured by that tool and are not written to error.log, so check both places.
WP Engine: log times are shown in UTC by default; you can switch to local time in Profile & Settings. The error log article's introduction mentions the most recent 24 hours of PHP errors while its table describes 48 hours, so treat 24 hours as the safe assumption. Filters include severity (4xx and 5xx), log type, status code and time ranges from 5 minutes to 2 days, and each access log row can show the verb, resource, status, referrer and user agent. WP Engine also links a guide to backing logs up automatically to Amazon S3.
SiteGround: the Error Log offers Copy to clipboard rather than a file download. For more than the 300 latest access entries of the current day, the knowledge base says to contact support before the data is archived; after that, the archived files in the logs directory cover up to 30 days.
DigitalOcean: the WordPress 1-Click image runs Ubuntu 24.04, the Caddy web server and PHP 8.3 FPM. There is no portal log viewer for this stack. You read Caddy's logs with journalctl and decide yourself how long to keep them, which is flexible but means nothing is retained unless you configure it.
Using WordPress's own debug log without exposing errors
When the host's error log does not show enough, WordPress can write its own log. The WordPress developer documentation says WP_DEBUG_LOG only works when WP_DEBUG is true, writes to wp-content/debug.log by default, and can be pointed at another path. WP_DEBUG_DISPLAY defaults to true, which prints errors on the page, so set it to false when logging.
The same documentation says these tools are not recommended on live sites and should be used in local or staging environments. On a membership site, reproduce the failed checkout on staging with debugging on, rather than leaving it on in production.
- define( 'WP_DEBUG', true ); turns debug mode on (write true without quotes; the string 'false' counts as true)
- define( 'WP_DEBUG_LOG', true ); writes to wp-content/debug.log, or give a path outside the web root
- define( 'WP_DEBUG_DISPLAY', false ); keeps errors off the page
- Turn all three off again when the issue is found, and delete the debug.log file
Worked example: tracing one failed checkout
A member reports that the checkout button spun and failed at about 2:05 pm Eastern on a Thursday in October, when Eastern time is UTC minus 4. That is 18:05 UTC, which is what WP Engine shows by default.
Step one, access log: filter the window 18:00 to 18:10 UTC for requests to the checkout page and to wp-admin/admin-ajax.php or the REST endpoint your checkout uses, and look for 4xx or 5xx statuses. If the member gives their IP address or browser, narrow by IP or user agent. Step two, error log: look for a PHP fatal error or warning at the same timestamp. Step three, download both files and attach them to the support ticket or plugin bug report, with the order or attempt ID from your payment processor.
If the access log shows a 200 response and the error log is clean, the failure probably happened in the browser or at the payment provider, and the next place to look is the provider's dashboard and webhook log rather than the host.
Checklist when a payment or login problem is reported
- Write down the time with its time zone and convert it to UTC before filtering
- Download that day's access and error logs immediately (Kinsta keeps up to 4 days; WP Engine error view covers up to 48 hours)
- On SiteGround, copy the Error Log and pull the archived access log file from the domain's logs folder
- On a Droplet, export the relevant journalctl output to a file before log rotation removes it
- Match access log status codes to error log entries by timestamp
- Store the files outside the host with the order ID and a one-line description
- Reproduce on staging with WP_DEBUG_LOG on rather than enabling debugging in production
Questions before you decide
How long does Kinsta keep server logs?
Kinsta's documentation says logs are retained for up to 4 days and cannot be manually cleared. Download the dated file you need from the logs folder in MyKinsta File manager or over SFTP before it ages out.
Can I download WP Engine error and access logs?
Yes. The User Portal Logs page lets you search, filter and download logs. The error view covers up to 1,500 errors from the last 48 hours, origin access logs show the most recent 1,500 requests, and edge logs can be downloaded for the past 72 hours, with links that expire after 24 hours.
Does SiteGround let me download the error log as a file?
The Error Log in Site Tools offers Copy to clipboard rather than a file download. Raw access logs are archived up to 30 days back in /home/username/www/domain.com/logs and can be fetched with File Manager, FTP or SSH.
Where are the logs on a DigitalOcean WordPress 1-Click Droplet?
On the server. The marketplace documentation shows Caddy's logs being read with journalctl -u caddy and PHP-FPM checked with systemctl status php8.3-fpm. There is no hosting dashboard log viewer, so retention depends on how you configure the server.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Kinsta docs: Server logs Accessed 30 Oct 2026
- Kinsta docs: File manager Accessed 30 Oct 2026
- WP Engine support: Error logs Accessed 30 Oct 2026
- WP Engine support: Access logs Accessed 30 Oct 2026
- SiteGround KB: Error log and export Accessed 30 Oct 2026
- SiteGround KB: Raw access logs Accessed 30 Oct 2026
- DigitalOcean docs: WordPress 1-Click Accessed 30 Oct 2026
- WordPress developer docs: Debugging in WordPress Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.