Where Are WordPress Logs? How to Find and Read Each Log Type

If your WordPress site has suddenly started showing a 500 Internal Server Error, a critical error message, or an unexpected change, you’re probably trying to figure out what went wrong and where to find reliable clues.

The good news is that the right log can usually point you toward the cause, whether it’s a WordPress or PHP issue, a server failure, a user action, or a problem with a connected service. This guide explains exactly where WordPress logs are, what each log records, and which one to check first. WordPress does not use a single universal log file.

Start with wp-content/debug.log for WordPress and PHP errors, your hosting provider’s error log for server failures, the access log for incoming requests, and an activity log for changes made inside WordPress.

Before changing a live site, create a fresh backup of your WordPress site with a WordPress backup plugin or your host. Disable temporary debugging after the investigation so visitors cannot see diagnostic details and old logs do not consume unnecessary storage.

What are WordPress logs?

WordPress logs are records of events produced by WordPress, PHP, the web server, a plugin, the database, an email service, or the server’s operating system. Each source answers a different question.

For example, a change log can show that a plugin was updated before a page broke. An activity log can show which account changed a setting. An access log can show repeated requests to a login page. A WooCommerce log can show where an order process stopped.

Logs provide evidence, not a complete answer. A 404 means that a requested page was not found, but it does not prove an attack. A warning may be harmless, while a fatal error can stop a page from loading. Check the time, pattern, related changes, and other records before deciding what happened.

Why logs matter

Logs reduce guesswork by turning a vague symptom into a timeline and a set of leads. They can show:

• What failed: the PHP function, file, request, database query, or connected service involved.
• When it failed: whether the event followed an update, happened during a traffic spike, or repeated on a schedule.
• What to investigate next: whether to contact the host, review an account change, isolate a plugin, check a payment gateway, or inspect a server resource.

They do not prove intent, identify a person with certainty, or repair the underlying problem. Their value comes from correlating the right log with the right time window and symptom.

The 10 types of WordPress logs

The term “WordPress logs” covers several types of records. Some are available in WordPress, some are created by plugins or services, and others belong to the hosting server. Their names and retention periods vary by host.

1. Change logs

Change logs record updates and modifications to a site, such as WordPress core, plugin, theme, configuration, or file changes. They are useful when a site starts showing an error after you update WordPress: compare the failure time with recent changes, then test or roll back the suspected change using a backup or staging copy. A host may provide this history in its site-management dashboard; otherwise, an activity tool, backup history, or maintenance record may provide part of it.

Change logs are not a universal WordPress feature. A record only exists if the host, plugin, deployment system, or activity tool was recording changes when they happened.

2. Activity or audit logs

Activity logs record actions inside WordPress, such as logins, user changes, post and page edits, plugin and theme changes, file and setting changes, comments, and WooCommerce events.

Use an activity log when the question is, “Who changed what?” If you need to check WordPress who is logged in or track user sessions, a dedicated log becomes essential.WordPress core provides limited histories, such as content revisions, but it does not keep a complete record of every administrator action by default. An activity logger must be installed and enabled before the event, so it cannot recreate an earlier change. It may also retain entries for only a limited period.

MalCare’s activity-log feature records categories such as posts, pages, comments, users, files, WooCommerce, plugins, and themes. If you are conducting a site-wide WordPress audit, search and filtering can help site owners review a specific account, category, action, keyword, or date. If no activity log was active, compare the time with revisions, backups, hosting history, access logs, and maintenance records. These sources can support an investigation, but they do not provide the same complete view.

An activity log is different from an access log. The activity log records an action recognized inside WordPress; the access log records a request received by the web server.

3. Server error logs

Server error logs record problems handled by the web server or hosting environment. They can explain 500 and 503 responses, permission problems, timeouts, PHP startup failures, and errors that occur before WordPress can write its own message.

Look in the hosting provider’s Monitoring, Logs, or Error Logs area. On a server you manage directly, the location depends on the web-server software and operating system. Managed and shared hosts may filter, shorten, rename, or withhold these records, so the host’s documentation is the authority for the exact location.

When asking a host for help, include the page or action, response code, approximate time and time zone, and whether the problem repeated. Ask for matching entries rather than an unrestricted log export.

4. WordPress debug logs

The WordPress debug log is usually the best first check for a broken plugin, theme, or custom code. It can record PHP errors, warnings, notices, and deprecated-code messages when debugging is enabled.

The usual file is wp-content/debug.log, but it will not exist until file logging is enabled and a related event occurs. The host may route PHP messages to another file, permissions may prevent the file from being written, or older entries may have been rotated. A missing debug.log does not prove that the site has no errors.

To capture a reproducible issue, add these constants to wp-config.php before the comment /* That's all, stop editing! Happy blogging. */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG enables diagnostic messages. WP_DEBUG_LOG saves them to wp-content/debug.log by default or to another valid path. WP_DEBUG_DISPLAY keeps the messages out of the page shown to visitors.

Create a backup first, reproduce the problem once, note the page and exact time, and inspect the newest matching entries through SFTP or the host’s file manager. Turn debugging off after collecting evidence. Debug logging helps locate a likely cause; it does not repair code, remove malware, or prove that the first entry caused the outage.

5. Web-server access logs

Access logs record requests received by the web server. An entry may include the client IP address, time, HTTP method, requested path, response code, response size, referrer, and browser or crawler information.

Use an access log to check whether a failure happened once or repeatedly, which page received the requests, or whether one source sent a burst of traffic. Repeated login requests, clusters of missing-page requests, or bursts of 500 and 503 responses are investigation signals. If the pattern suggests compromise, a WordPress malware scan can help check whether suspicious requests correspond to a broader infection. One unfamiliar IP address is not proof of a compromise because proxies, shared networks, and crawlers can make the source difficult to identify.

Find access logs in the host’s monitoring panel, cPanel under Raw Access Logs, or the server’s log directory. An access log shows that a request reached the server. It does not establish which authenticated person made a WordPress change.

6. PHP error logs

PHP error logs record errors produced by PHP, the programming language WordPress uses. They may contain syntax errors, warnings, fatal errors, database-connection failures, and theme or plugin problems.

PHP errors are often stored by the host separately from wp-content/debug.log. Check the hosting dashboard, PHP monitoring panel, or the location configured by the server’s error_log setting. On some servers, an administrator may need to review php.ini. Do not change server-wide PHP settings unless you understand their scope and have a recovery path.

PHP logs are especially useful when WordPress does not load far enough to write its own debug entry. A PHP entry commonly includes a timestamp, severity, message, file path, and line number. These identify a lead, not always the original cause.

7. WooCommerce logs

WooCommerce logs record checkout, order, payment, shipping, product, and extension events, with timestamps that help match a customer action to a failure.

In the WordPress admin area, go to WooCommerce > Status > Logs, select the relevant file, and choose View. Payment and shipping providers may also keep their own records. A WooCommerce error log can show where the WordPress-side process stopped, but the payment provider has the final record of what happened to a payment. Before making store changes, back up WooCommerce so you have a restore point.

8. MySQL and database logs

Database logs record activity and errors in the database used by WordPress. They can help with failed connections, rejected queries, table problems, and slow queries.

The host or database administrator controls these logs. On some systems they appear in locations such as /var/log/mysql; on managed hosting they may be available only through a control panel or support request. MySQL error logs and slow-query logs answer different questions, and high-volume query logging can add overhead.

Before changing database settings, make a WordPress database backup.

For a short investigation, WordPress’s SAVEQUERIES setting can retain query timing and the code that called each query, but it should be disabled after the investigation. Do not leave verbose database logging enabled on a busy production site without a specific reason.

9. SMTP and email logs

SMTP logs record email attempts made through Simple Mail Transfer Protocol. They can show when WordPress or an email service tried to send a password reset, form notification, order email, or newsletter, plus delivery status and provider errors.

Check the dashboard of the SMTP provider or mail service. If the site does not use an external provider, an email-log feature in a mail plugin may record the WordPress-side send attempt. A send attempt does not prove that the recipient’s mailbox accepted, displayed, or did not filter the message. The provider’s delivery record is the stronger evidence for that part of the journey.

10. System logs

System logs, often called syslogs, record events from the server’s operating system, network services, security controls, and applications. They help when the problem involves disk space, system processes, network failures, firewall rules, or a server-wide event.

On a server you administer, common locations include /var/log/syslog or /var/log/messages, but the operating system and host determine the actual location. Firewall logs can show blocked requests, file-transfer logs can show SFTP sessions, and managed-host runtime or request logs may provide a more focused view. Most WordPress site owners need to ask their host or administrator for these records.

Find the log that matches the problem

Use this guide to choose where to start:

If you have WordPress administrator access but not server access, you may not be able to open web-server, database, or operating-system logs. Ask the host for entries from the exact time window and include the site’s time zone.

A safe way to investigate

Use this sequence when an error or suspicious change first appears:

• Describe the symptom. Record the affected URL or admin action, the visible message, the first time you noticed it, and the site’s time zone.
• Preserve the current state. Take a backup or snapshot before changing plugins, themes, configuration, or database settings.
• Choose the narrowest relevant log. Start with the log closest to the failure, then check the host or service log if the first source is empty or incomplete.
• Reproduce once when safe. Repeat the action in a WordPress staging environment, or on the live site only when the action is low risk. Record the exact time so the matching entries are easy to find.
• Correlate before changing anything. Compare the error with recent updates, activity events, access requests, resource limits, and connected-service records.
• Test the smallest fix. Isolate one plugin, theme, setting, query, or service at a time. Verify the result on staging when possible, then remove temporary logging and protect the evidence.

How to read a log entry

Start with the newest entry that matches the failed action. Then use surrounding lines only when they add context.

1. Match the timestamp. Check the site and server time zones. Record the time when the error, request, change, order, or email occurred.
2. Check the severity. A fatal error can stop execution. A warning, notice, or deprecated-code message may still matter, but it is not automatically the cause of an outage.
3. Read the message. Look for the plugin, theme, function, missing file, database response, request, or service named in the entry.
4. Use the file and line as a lead. Do not edit a file just because its path appears. A plugin may have called it incorrectly, or a server change may have exposed a compatibility problem.
5. Match the action. Compare the entry with the page, request type, account, scheduled task, store action, or email recipient involved.
6. Look for a pattern. Several matching entries around the same time are more useful than one isolated warning. Correlate activity, access, error, and service logs when the incident crosses system layers, and compare the timing with the plugin update history.

Protect and manage WordPress logs

Logs can contain IP addresses, usernames, email addresses, server paths, request data, session information, or secrets accidentally written by code. Treat them as sensitive information.

• Keep log files outside publicly reachable web paths. A file that can be opened through a normal website address is not safely stored.
• Limit access to the people investigating the issue. Use the host’s file and dashboard permissions correctly.
• Redact passwords, access keys, session cookies, email addresses, and unnecessary personal data before sharing an entry.
• Monitor storage and retention. High-volume access, PHP, or query logs can fill disk space, and hosts may rotate, sample, truncate, or delete old entries.
• Back up the site before making a live change. Test the fix on a private staging copy when possible, then keep the restore point until the site works normally. Test your WordPress backups before relying on one for recovery.
• Use WordPress monitoring to set alerts for important activity or repeated errors when your host, security tool, or log manager supports them.
• Disable temporary debug, query, or verbose logging after the investigation. Keep only the history needed for troubleshooting, security, legal, or operational purposes.

Do not block an IP address based on one access-log line. Confirm the pattern first, then use the appropriate firewall or host control if the evidence supports it.

FAQs

Conclusion

When you search for where WordPress logs are, first match the log to the symptom. Use change and activity logs for site history, debug and PHP logs for code errors, server error logs for server failures, access logs for incoming requests, and specialist logs for stores, email, databases, and the operating system.

Read entries as clues, not verdicts. Record the time, protect the files, keep a restore point ready before making changes, and turn off temporary debugging when you have the evidence you need. If the evidence points to slow server response rather than an application error,

Written by

Shivani M

Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.