WordPress debug mode surfaces PHP errors, warnings, and notices that are otherwise hidden from both the admin panel and the front end of your site. On a Kinsta-hosted site, you can enable it without touching a single file: MyKinsta has a built-in toggle that writes the necessary constants to wp-config.php on your behalf. This guide covers how to turn it on, where to find the output, how to read what the log is telling you, and when to turn it off.
What WordPress Debug Mode Does
When you enable WordPress debug mode in MyKinsta, the platform sets WP_DEBUG to true on your site. This tells WordPress to log all PHP errors, deprecated function notices, and warnings to an error log rather than displaying them on screen (or displaying a generic error page). The logs give you the specific file and line number where an issue occurred, which makes diagnosing plugin conflicts, theme errors, or custom code problems significantly faster than guessing.
For performance slowdowns rather than PHP errors, the Kinsta APM tool captures PHP execution times and slow database queries. It is a useful companion when debug mode shows no PHP errors but the site is still slow.
WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY
WordPress uses three separate constants to control debugging behavior. Understanding each one helps you interpret what MyKinsta actually does when you click Enable.
- WP_DEBUG: The master switch. Setting this to true tells WordPress to report all errors, notices, and warnings. Without this set to true, the other constants have no effect.
- WP_DEBUG_LOG: Controls whether errors are written to a log file (wp-content/debug.log). When this is true, errors are recorded to the log rather than displayed on the page. MyKinsta routes these logs to the error.log file visible in your dashboard.
- WP_DEBUG_DISPLAY: Controls whether errors are printed directly on the page. MyKinsta sets this to false by default, so your visitors never see raw PHP errors even when debug mode is on. Errors go to the log only.
MyKinsta configures all three constants for you when you click Enable under WordPress Debugging. WP_DEBUG is set to true, WP_DEBUG_LOG is set to true, and WP_DEBUG_DISPLAY is set to false. You get the full error log without exposing errors to site visitors.
How to Enable WordPress Debug Mode in MyKinsta
- Log into your MyKinsta dashboard
- Select the site where you want to enable debugging from the Sites list
- Click the Tools tab within the site’s dashboard
- Under WordPress Debugging, click Enable
Debug mode is now active on that site. You will see the toggle switch to an enabled state. WordPress begins logging PHP errors to the error log immediately. There is no need to restart the server or clear the cache; the change takes effect on the next page load.
Staging vs. Production: Where to Enable Debug Mode
Always enable debug mode on a staging environment first. Kinsta creates a free staging environment for every site (Sites > your site > Staging). Enabling debug on staging lets you reproduce the error without any risk of exposing log paths or server information to real visitors. If the error only appears on production (a specific database state, a cron job, a live payment hook), enable debug mode on production for the minimum time needed to capture the log entry, then disable it immediately. Never leave WP_DEBUG enabled on a live site indefinitely.
How to Read the MyKinsta Error Log
Enabling debug mode is the easy part. The log it generates requires some interpretation: not every entry is a crisis, and knowing which lines demand immediate attention saves significant time.
Where to Find the Log in MyKinsta
Go to Sites > your site > Logs tab. From the dropdown, select error.log. MyKinsta streams the log file directly in the browser so you do not need SFTP or file manager access. The log updates in near real-time; reload the Logs tab after triggering the error to see new entries appear.
The physical file lives at wp-content/debug.log in your site’s root directory. On Kinsta’s server structure that path resolves to something like /www/wwwroot/yoursite/wp-content/debug.log. You can also download it via SFTP if you need to search a large log locally.
Anatomy of a Log Entry
Every line in the WordPress debug log follows the same format. Here is a realistic example:
[18-Jun-2026 10:23:44 UTC] PHP Fatal error: Call to undefined function get_header() in /www/wwwroot/mysite/wp-content/themes/mytheme/functions.php on line 47Breaking that down:
- [18-Jun-2026 10:23:44 UTC] is the timestamp. When you have hundreds of log lines, filter by timestamp to find entries that appeared right after you triggered the problem.
- PHP Fatal error is the error level. This is the part that tells you how urgently to act.
- Call to undefined function get_header() is the error message: a function named get_header() was called but PHP could not find its definition.
- /www/wwwroot/mysite/wp-content/themes/mytheme/functions.php is the file path where the error was triggered. This points you to the exact file to open.
- on line 47 is the line number. Open the file, go to line 47, and that is where the code called the missing function.
Error Levels: Which Ones Actually Matter
The WordPress debug log mixes genuinely serious errors with low-priority notices that many plugins produce routinely. Treating every log line as urgent leads to wasted debugging sessions. Here is how to triage:
- PHP Fatal error is the highest severity. A fatal error stops PHP execution at that point, which means the page or function that triggered it will not finish loading. Investigate immediately.
- PHP Warning is serious but non-fatal. The code encountered something unexpected (like a function receiving the wrong argument type), but PHP kept running. Warnings often indicate a bug that will become a fatal error under different conditions.
- PHP Notice is informational. The code is doing something technically imprecise but it did not break. Many legacy plugins and themes produce dozens of notices permanently. They are worth fixing in your own code but not worth chasing in third-party plugins unless they are paired with visible errors.
- PHP Deprecated means the code is calling a PHP function or feature that will be removed in a future PHP version. Deprecation notices matter most when you are planning a PHP version upgrade; they will become fatal errors once the deprecated feature is removed.
A practical triage rule: fix every Fatal and Warning in your log before investigating Notices or Deprecated lines. If your log contains only Notices and Deprecated entries and your site is functioning correctly, those can wait.
Common WordPress Errors You’ll See (and What They Mean)
Four error patterns account for the majority of WordPress debug log entries. Each one points to a specific type of problem with a specific fix.
“Call to undefined function”
This error means a function was called that PHP cannot find. In WordPress, this almost always means the plugin or theme that defines the function is either deactivated or was not loaded yet when the calling code ran. The log entry shows the file and line that made the call. Trace back to which plugin or theme defines that function name, then check whether that plugin is active. If the function is in a plugin that is active, the problem may be a load order issue: one plugin is calling another plugin’s function before that plugin has initialised. Wrapping the call in a function_exists() check is the standard fix for load order problems in plugin development.
“Maximum execution time of X seconds exceeded”
PHP enforces a maximum time limit on how long a script can run. When a query, API call, or loop takes longer than that limit (commonly 30 or 60 seconds), PHP kills the process and logs this error. On Kinsta, you can increase the PHP timeout limit from MyKinsta > Sites > your site > Tools > PHP configuration. Set max_execution_time to 120 or 300 for operations you know are legitimately slow (large imports, bulk email sends). However, increasing the timeout is a workaround, not a fix: if a routine operation is hitting the time limit, it is usually because a database query is unindexed, an external API call is hanging, or a loop is iterating over a dataset that should be processed in batches.
“Allowed memory size of X bytes exhausted”
A plugin or theme operation tried to allocate more RAM than PHP’s memory limit allows. WordPress sets a default limit of 40 MB, which is low enough that many modern plugins hit it. The standard fix is to add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or to set the limit via Kinsta’s PHP configuration panel. If you are hitting memory limits on Kinsta, the triggering operation is likely doing something genuinely expensive: importing a large CSV row-by-row into memory, generating a large image manipulation, or loading an entire dataset into a PHP array rather than querying it in pages.
“Cannot redeclare function X”
Two separate files define a function with the same name, and PHP loaded both. This is always a plugin conflict. The debug log will show two file paths: the first file where the function was originally defined, and the second file that tried to define it again. Deactivate plugins one at a time, starting with recently installed or updated ones, until the error stops appearing. The two plugins whose file paths appear in the log entry are the conflicting pair.
When to Disable Debug Mode
After you have worked through the errors in the log, disable debug mode before the site sees any meaningful traffic. PHP errors that surface function names, file paths, and database query details are useful to you and also useful to anyone with malicious intent who happens to visit the site while debug mode is on. Turn it off from the same MyKinsta Tools tab where you enabled it.
Final Word: How to Enable WordPress Debug Mode in MyKinsta
Enabling WordPress debug mode through MyKinsta takes four clicks and requires no manual file editing. Once enabled, the error log gives you the specific PHP error and file location so you can fix the problem quickly. Always disable debug mode when you are done. It should not be left on in production. Read more about Kinsta’s managed WordPress features in our Kinsta review. If you want to make sure you receive downtime alerts automatically, check your MyKinsta notifications settings to confirm Site Monitoring is enabled.
