Fatal Error During WordPress Update - How to Recover

You click "Update WordPress" or "Update Theme" and the page starts loading. Then it stops. Nothing happens for 30 seconds. Then you see it:

Fatal error: Allowed memory size of 134217728 bytes exhausted

Or:

Parse error: syntax error, unexpected end of file

Or just a blank white screen.

Your site is down. The update is halfway done. Some files have been replaced. Some haven't. The database might be partially migrated. You don't know what state your site is in.

This is the nightmare scenario. It happened to a client during a core update. WordPress tried to extract files, ran out of memory, PHP crashed, and left the installation in a half-updated state. Their frontend was a white screen. Their admin wouldn't load.

We recovered it in 25 minutes. Their data was completely safe. But we had to know exactly which steps to take.

This guide is those steps. Follow them in order and you will get your site back online.


What Fatal Errors During Updates Actually Mean

A fatal error during an update means PHP crashed in the middle of the process. One of these steps failed:

  1. Download update files
  2. Extract files
  3. Backup current installation
  4. Move new files to live location
  5. Run database migrations
  6. Verify installation integrity

When PHP hits an error it can't recover from, it stops running. The update stops midway. Files are in a mixed state—some old, some new.

The most common fatal errors:

  • Memory exhausted: PHP ran out of memory (usually during file extraction). Most common.
  • Parse error: A PHP file has a syntax error. Usually means the file extraction was corrupted or incomplete.
  • Maximum execution time exceeded: The update took longer than max_execution_time. PHP killed the process.
  • Undefined function: A file didn't extract completely. PHP is trying to run a function from a partial file.
  • Database connection lost: During database migration, the connection dropped. Database is in a half-migrated state.
  • Disk full: The server ran out of disk space during extraction. Files are incomplete.

Important truth: A fatal error during update does NOT mean your data is lost. Your database files are stored separately. Your wp-content folder (plugins, themes, uploads) is usually intact. Only the WordPress core files or theme files are in a bad state.


Step 1: Stop Panicking and Get Access to Your Server

First, your site is down. You need to get into your server via SSH or FTP, not through WordPress admin.

Connect via SSH (If you have terminal access)

ssh user@yourserver.com

Or through your hosting control panel (cPanel, Plesk, etc.) if they provide a terminal.

Connect via FTP (If you don't have SSH)

  1. Use an FTP client (FileZilla, WinSCP, Cyberduck)
  2. Enter your hosting credentials
  3. Connect to your server

Do not try to fix this through the WordPress admin. If WordPress is showing a fatal error, the admin is likely broken too. You need direct server access.


Step 2: Enable Debug Logging to See the Error

You need to see the actual error to know what happened.

Via FTP or SSH, edit wp-config.php

  1. Navigate to your WordPress root directory
  2. Download (FTP) or open (SSH) wp-config.php
  3. Find the line: define( 'WP_DEBUG', false );
  4. Change it to:
    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
  5. Save and upload (FTP) or save (SSH)

Visit your site

Go to yoursite.com. It might still show an error, but now WordPress is logging the details.

Check the debug log

  1. Download wp-content/debug.log via FTP or SSH
  2. Look at the end of the file for the most recent entries
  3. The fatal error message will be there with a file name and line number

Now you know exactly what failed. This shapes your next steps.


Step 3: Restore from Backup (Fastest Recovery)

If you have a backup from before the update started, restoring it is the fastest fix.

Check if you have backups

  • Do you use UpdraftPlus? (Check Plugins > Installed Plugins)
  • Do you use BackWPup?
  • Does your hosting provider offer backups? (Check cPanel or Plesk)
  • Do you have manual backups you took recently?

Restore the backup

Via UpdraftPlus:

  1. Go to Plugins and try to find UpdraftPlus (might not be accessible if site is down)
  2. If admin is accessible, go to Updraft > Existing Backups
  3. Find the backup from before the update started
  4. Click "Restore"
  5. Choose which components to restore (WordPress core, plugins, themes, database)
  6. For a fatal update error, restore: WordPress core + database
  7. Wait for restoration to complete

Via hosting provider backup:

  1. Log into your hosting control panel (cPanel, Plesk, etc.)
  2. Find Backups or File Manager
  3. Look for a backup from before the update
  4. Restore it (usually one-click in the control panel)
  5. Wait 5-10 minutes for restoration

Via manual backup:

  1. If you have a .zip backup you took previously, extract it on your computer
  2. Upload the old files via FTP to your server (overwrite the broken files)
  3. For database, if you have an SQL backup, import it via phpMyAdmin

After restoration:

  1. Visit your site—it should work again
  2. Check that everything loads correctly
  3. Test a few pages and admin functions

Time to recover: 5-15 minutes. Your site is back online.


Step 4: If No Backup - Partial Recovery

If you don't have a backup, you can often recover by rolling back the partially-updated files.

Check what's in the upgrade folder

WordPress keeps backup copies during updates.

  1. Connect via SSH or FTP
  2. Navigate to wp-content/
  3. Look for an upgrade folder or upgrade-backup folder
  4. These folders contain copies of the old files

Restore from the backup folder

If you see an upgrade-backup folder:

cd wp-content/
rm -rf wp-admin wp-includes
mv upgrade-backup/wp-admin ./
mv upgrade-backup/wp-includes ./
rm -rf upgrade upgrade-backup

This restores the old WordPress core files from the backup.

If no backup folder exists

The update might have failed before it created a backup. In this case:

  1. Go to wordpress.org and download the version you were on before the update
  2. Extract it on your computer
  3. Upload wp-admin and wp-includes folders via FTP (overwrite the broken ones)
  4. Leave wp-content alone

Why this works: The critical WordPress core files are now restored. wp-content (your plugins, themes, uploads) is usually intact.

Test the site

  1. Visit yoursite.com
  2. Does it load?
  3. Try logging into admin
  4. Try editing a post

If it works: You've recovered. Your site is stable on the old version. Go to Step 5.

If it still shows an error: Continue to Step 6.


Step 5: Verify Database Integrity

If the fatal error happened during database migration, the database might be partially updated. The files are restored, but the database schema might be broken.

Try to access WordPress admin

Log in and try basic operations:

  • View posts (does the list load?)
  • Edit a post (does it save?)
  • Check plugin settings
  • Look at debug.log for database errors

If there are database errors:

Run WordPress database repair

  1. Edit wp-config.php
  2. Add this line BEFORE the final line:
    define( 'WP_ALLOW_REPAIR', true );
  3. Visit: yoursite.com/wp-admin/maint/repair.php
  4. Click "Repair Database"
  5. Wait for it to finish
  6. Remove the WP_ALLOW_REPAIR line from wp-config.php (security)
  7. Test your site

This fixes most database corruption issues from failed updates.

If database repair doesn't work

The database might be too corrupted. You'll need to manually restore it.

  1. Via phpMyAdmin (in your hosting control panel), select your WordPress database
  2. Go to Export
  3. Export to file (this is a backup of the current corrupted database)
  4. Contact your hosting provider and ask for a database restore from before the update
  5. Or, if you have a previous database backup, import it

This is getting into deep territory. At this point, contact your hosting provider's support. They can restore the database from their backups.


Step 6: If Nothing Worked - The Nuclear Option

If you've tried everything and the site still won't work, do a complete fresh install and restore your content.

Backup what you can

Before doing anything drastic:

  1. Download your wp-content folder (contains your uploads, plugins, themes)
  2. Export the database (even if corrupted, you might be able to save some data)
  3. Make a complete backup of the entire site as it is now

Fresh WordPress install

  1. Delete wp-admin and wp-includes folders
  2. Delete all .php files in the root (except wp-config.php)
  3. Download the latest WordPress version from wordpress.org
  4. Extract it on your computer
  5. Upload wp-admin, wp-includes, and all root .php files via FTP
  6. Leave wp-config.php alone (you already have it)
  7. Leave wp-content alone (your data is there)

Run the WordPress setup

  1. Visit yoursite.com/wp-admin
  2. You might see "WordPress database needs to be updated"
  3. Click to update the database
  4. Try to log in

If database is corrupted beyond repair:

  1. Use the WordPress database repair tool (see Step 5)
  2. If that doesn't work, you might need to manually recreate the database tables
  3. At this point, contact your hosting provider. This is beyond typical troubleshooting.

Step 7: Prevent It Happening Again

Once you're recovered, make sure this never happens again.

Fix the root cause

If memory was the issue:

define( 'WP_MEMORY_LIMIT', '256M' );

If timeout was the issue: Add to .htaccess:

php_value max_execution_time 300

If disk space was the issue: Delete old files or upgrade hosting.

If database was the issue: Clean up the database and optimize tables.

Set up automatic backups

Install UpdraftPlus or BackWPup and configure daily automatic backups. Store them off-site (Google Drive, Amazon S3, etc.).

Update during maintenance windows

Update at 2-3am, not during business hours. Less traffic = less stress on the server.

Use staging environment

Test updates on a staging environment before production.

Increase PHP limits preemptively

Before any major WordPress core update, increase memory_limit and max_execution_time. Don't wait for an error.


Real-World Fatal Update Error Story

Scenario: A client's WordPress site (30,000 posts, 50+ plugins) tried to auto-update to a new WordPress version. Midway through, they got "Allowed memory size exhausted" fatal error. Their site was down. They called us at 3pm on a Friday.

What happened:

  • WordPress tried to extract 500MB of core files
  • PHP memory limit was 128MB (way too low for a site that large)
  • Extraction failed halfway through
  • Database migration never even started
  • Files were in a mixed state—new version partially there, old version partially deleted

Our recovery:

  1. Checked debug.log and saw "Allowed memory size" error
  2. Found wp-content/upgrade-backup folder with the old files
  3. Restored wp-admin and wp-includes from the backup (3 minutes)
  4. Site loaded again (5 minutes)
  5. Edited wp-config.php and increased memory to 512M (2 minutes)
  6. Tested the site thoroughly (5 minutes)
  7. Tried the update again—it worked (10 minutes)

Total downtime: 25 minutes. Data loss: zero. Database loss: zero.

What we learned: Large WordPress sites need more PHP memory than the default. We set up a monitoring alert to check memory usage before future updates.


When to Contact Hosting Support

Contact your hosting provider if:

  • You've restored from backup and the database is still corrupted
  • Database repair tool doesn't fix the issues
  • You've restored files but the site still shows fatal errors
  • You've run out of disk space and need to clean up
  • They have server-level backups older than the failed update
  • You need help accessing database tools or file restoration options

What to tell them:

  • "WordPress update failed with a fatal error at [time]. Site went down. I need help restoring from backup."
  • Include the error message from debug.log
  • Include your WordPress version and theme/plugin list
  • Let them take it from there—they can often restore faster than you can

Most hosting providers respond within 1 hour for downtime issues. They want to get you back online as much as you do.


Fatal Update Error Troubleshooting Checklist

Site is down with fatal error during update?

  • ✓ Connect via SSH or FTP (not through WordPress admin)
  • ✓ Enable debug logging in wp-config.php
  • ✓ Check debug.log to see the exact error
  • ✓ Restore from backup (if available) — fastest recovery
  • ✓ If no backup, restore from upgrade-backup folder or download previous version
  • ✓ Test the site — does it load?

Site loads but has errors:

  • ✓ Check debug.log for ongoing errors
  • ✓ Run database repair if database errors show
  • ✓ Clear all caches
  • ✓ Disable all plugins and test
  • ✓ Switch to default theme and test

Once stable, fix the root cause:

  • ✓ Increase PHP memory_limit if memory error occurred
  • ✓ Increase max_execution_time if timeout error occurred
  • ✓ Free up disk space if storage error occurred
  • ✓ Set up automatic backups
  • ✓ Try the update again (it should work now)

The Real Talk

A fatal error during update is objectively scary. Your site is down. You can't get into WordPress admin. You don't know if you'll lose your data.

Here's what actually happens: WordPress has multiple backup mechanisms. Your files are usually backed up before they're overwritten. Your database is separate from the files. Your wp-content folder (containing your actual content, plugins, themes, images) is almost always untouched.

The worst-case scenario is that you restore from a backup and lose the last few hours of changes. That's not losing data—that's losing recent edits. Your actual content is safe.

The steps in this guide work. Follow them in order. You will get your site back online. It might take an hour. It might take 30 minutes. But you will recover.

The key is staying calm, getting server access, enabling debug logging, and methodically working through the recovery steps. Don't panic and delete things randomly. Don't try to fix it through a broken WordPress admin. Get direct server access and fix it from there.

You've got this.