If an update has failed, the safest next step is to stop, assess the current state of the site, and recover from a known-good copy before trying again. In a hosting environment, a failed update can affect the CMS, plugins, themes, database structure, PHP compatibility, cached files, or file permissions. On managed hosting platforms and in control panels such as Plesk, the quickest path to recovery is usually to confirm the failure, restore the affected files or database from a backup, and then repeat the update in a controlled way.
This guide explains how to respond to a failed update on a hosted website, how to recover safely, and how to reduce the chance of the issue happening again. It is especially useful for WordPress, Joomla, Drupal, and other PHP-based applications hosted on European infrastructure.
What a failed update usually means
A failed update can happen at several layers of the hosting stack. Sometimes the application itself partially updates and then stops. In other cases the hosting environment blocks the process because of resource limits, permissions, or file locks. A failed update may leave the site in maintenance mode, break the front end, or make the admin area inaccessible.
Common symptoms include:
- White screen or blank page after updating.
- Maintenance mode stuck on the website.
- Error messages about missing files, database errors, or undefined functions.
- Broken layout, missing images, or JavaScript errors.
- Cannot log in to the control panel or CMS admin area.
- 404 errors after a plugin, theme, or platform update.
- PHP fatal errors shown in the browser or error logs.
In many cases, the update did not fail completely. Instead, it finished only part of the job. That is why recovery should focus first on stability, then on diagnosis.
First steps to take after an update fails
Do not immediately run the update again. Repeating the same action without checking the current state can make the problem worse. Start with a short checklist to avoid accidental data loss.
1. Confirm what changed
Identify exactly what was updated: core application, plugin, theme, PHP version, database schema, or server-side package. If you manage multiple sites in a hosting platform, make sure you are working on the correct subscription or domain.
2. Check whether the site is in maintenance mode
Some CMS platforms create a temporary maintenance file during updates. If the process is interrupted, the site may remain locked. In a file manager or via FTP/SFTP, look for maintenance-related files in the root directory of the site. Remove only the file that was created for the update process, and only after confirming that the update really stopped.
3. Review error messages and logs
Use the application logs, PHP error log, and web server logs to identify the cause. In a hosting control panel, logs are often available under the domain’s log section. In Plesk, you can usually review web server and application logs from the domain view. Look for:
- PHP memory limit errors.
- File permission denials.
- Missing class or function errors.
- Database connection failures.
- Timeouts during file extraction or database migration.
4. Avoid editing live content until recovery is complete
If the site is generating sales, capturing leads, or handling customer requests, keep changes to a minimum. If possible, place the site in a temporary maintenance page so visitors do not interact with a broken checkout, form, or login flow.
Decide whether to restore files, database, or both
The correct recovery method depends on what the update affected. In many cases, a failed update changes both files and database structure, so a full restore is the safest option. In other cases, only one component needs to be rolled back.
Restore only files if:
- The update changed plugin or theme files but did not migrate the database.
- The issue is caused by a missing template, broken script, or corrupted package extraction.
- The site was working before the file update, and the database still appears healthy.
Restore only the database if:
- The update modified settings, content, or schema and the file set is intact.
- The application now shows database errors, incompatible tables, or broken admin pages.
- You need to revert a plugin update that changed stored options or records.
Restore both files and database if:
- The update was interrupted in the middle of a core upgrade.
- You see widespread errors across the front end and admin area.
- You are not sure which part was altered, and you have a recent backup point.
When in doubt, restoring both from the same backup snapshot is often the most reliable option. It keeps files and database in sync.
How to recover safely from a failed update
Use a staged, low-risk recovery approach. If your hosting platform provides restore points, snapshots, or backups in the control panel, start there. If not, use SFTP and database access to manually revert the affected parts.
Step 1: Create a current backup before changing anything
Even if the website is broken, make a backup of the current state before restoring. This preserves evidence of the failure and gives you a fallback if the restore does not go as planned. In a managed hosting environment, this can usually be done from the backup tool in the panel.
Step 2: Restore from the latest known-good backup
Choose a restore point from before the failed update. If available, pick the closest recent snapshot taken when the site was working correctly. Make sure the restore includes the correct domain and document root, especially if you host several sites on one account.
In platforms like Plesk, restore tools typically allow you to bring back:
- Website files.
- Databases.
- Mailboxes, if relevant.
- Configuration files and scheduled tasks.
If the update only affected one application, you may be able to restore just that application directory and its database, rather than the entire hosting subscription.
Step 3: Verify file integrity after restore
Check that the expected files are present and that the web root contains the correct application version. If the restore was partial, compare the restored files with the backup contents. Confirm that critical directories such as uploads, cache, and configuration folders are correct.
Step 4: Repair permissions and ownership if needed
Failed updates can leave files with incorrect permissions. This often affects PHP applications that need to write cache files or update configuration files. On managed hosting, use the panel’s file tools or ask support to confirm the correct ownership and permission set. Avoid setting overly broad permissions just to make the site work.
Step 5: Clear caches
After restoring, clear application cache, browser cache, and any server-side cache. If your hosting platform uses opcode cache, reverse proxy cache, or CDN integration, clear those layers as well. Cached broken assets can make the site appear still damaged even after a successful restore.
Step 6: Test the restored site before re-running the update
Open the homepage, important internal pages, the login area, and any checkout or contact forms. Confirm that:
- The site loads without fatal errors.
- Images, stylesheets, and scripts load correctly.
- The admin area works.
- Forms submit successfully.
- Database-driven content displays as expected.
If possible, test the update on a staging site first. Many hosting platforms offer staging copies or separate restore targets for safe testing.
Handling common failed update scenarios
WordPress core update failed
If a WordPress core update fails, the site may remain in maintenance mode or show a partial upgrade message. First, verify whether the database upgrade completed. Then check the wp-content directory for plugin conflicts. In many cases, restoring the pre-update backup and reapplying the update after increasing PHP memory or removing conflicting plugins is the best approach.
Plugin update failed
A plugin update can break the front end, admin pages, or a specific feature. If you know the plugin name, you may be able to deactivate it by renaming its folder through the file manager or SFTP. After the site is stable, restore the plugin folder from backup or reinstall a compatible version.
Theme update failed
Theme failures often affect layout or template rendering. If the active theme is broken, switch to a default theme temporarily if the CMS permits it. Then restore the previous theme files and verify custom templates, child theme files, and CSS overrides.
PHP version update failed
Sometimes the update that failed was not in the CMS, but in the hosting environment itself. A PHP version change can expose incompatible code. If the site breaks after a PHP switch, revert to the previous supported version, then review error logs and update extensions or application code before trying again.
Database migration failed
Database migrations may leave schema changes incomplete. This can cause missing fields, broken admin forms, or content errors. Restoring the database to the pre-update state is usually the safest option. If the application provides a repair tool, run it only after a backup is secured.
Using Plesk or a control panel for recovery
In a hosting control panel, recovery is often faster because backup and restore tools are integrated. If you use Plesk, look for the domain’s backup manager or restore options. Depending on your plan, you may be able to restore a single file, a whole directory, a database, or the entire subscription.
Useful control panel actions include:
- Restoring the site from a specific snapshot.
- Checking disk usage to confirm the update did not exhaust storage.
- Reviewing logs for failed file operations.
- Adjusting PHP settings such as memory limit or execution time.
- Managing file permissions through the file manager.
If your update failed because the process timed out or ran out of memory, adjust the environment only after restoring stability. Do not permanently increase limits without understanding the root cause.
How to prevent failed updates in the future
Once the website is recovered, improve the update process so the same issue does not repeat. A few simple practices can reduce risk significantly.
Keep regular backups
Use automated backups with a retention policy that keeps several restore points. For active websites, daily backups are often a minimum requirement. Make sure the backup includes both files and databases, and test restores periodically.
Use a staging environment
Test updates on a staging copy before applying them to production. This is particularly important for ecommerce sites, membership platforms, and custom PHP applications. A staging environment helps you detect plugin conflicts, PHP incompatibilities, and database changes early.
Update in small steps
Do not update everything at once if you can avoid it. Update one component, test it, then continue. This makes it easier to identify the exact cause if something breaks.
Check compatibility first
Review version requirements for the CMS, plugins, themes, and PHP. A feature that works on one PHP version may fail on another. Compatibility issues are a common reason for update failures on hosted platforms.
Monitor disk space and resource limits
Updates need temporary space to unpack files and rebuild caches. Low disk space, CPU limits, or short execution times can interrupt the process. Before updating, verify that there is enough free space and that the hosting plan can handle the operation.
Document the recovery process
Keep a short internal note of what was updated, when it was updated, and what restore point fixed the issue. This helps if the same problem occurs again or if another administrator needs to troubleshoot the site later.
When to contact hosting support
Contact support if you cannot restore the site through the control panel, if backups are unavailable, or if the failure affects multiple hosted services. Support can often check server-side logs, restore snapshots, or confirm whether the update failed because of platform-level restrictions.
Reach out promptly if you see:
- Repeated restore failures.
- Database corruption.
- Permission errors you cannot fix from the panel.
- Unexpected file loss after the update.
- Site-wide errors after a platform or PHP change.
When you contact support, include the time of the failed update, the affected domain, what was changed, and any error messages you observed. This speeds up diagnosis.
FAQ
Should I try the update again right away?
Not before checking logs and confirming the site is restored to a stable state. Repeating the update without fixing the cause may create a larger problem.
Is it safer to restore the whole site or only one part?
If you are unsure, restoring both files and database from the same backup is usually safest. If the issue is clearly limited to a plugin, theme, or one database change, a partial restore may be enough.
What if I do not have a recent backup?
Stop making changes and contact hosting support. They may still have platform snapshots or server backups. If no backup exists, recovery may require manual repair from logs and file comparison.
Can a failed update be caused by permissions?
Yes. Incorrect file ownership or permissions can stop updates, especially when the application needs to write configuration or cache files.
Why does the site still look broken after restore?
Cached content, CDN cache, browser cache, or an opcode cache may still be serving old broken assets. Clear all cache layers and retest in a private browser window.
Should I update on production if the site is busy?
It is better to update in staging first and schedule production changes during a low-traffic window. This reduces the impact if anything fails.
Conclusion
After a failed update, the safest recovery path is to pause, identify what changed, and restore the site to a known-good state before retrying. In a managed hosting environment, the combination of backups, logs, and control panel tools such as Plesk can make recovery fast and controlled. Once the website is stable again, test the update in staging, verify compatibility, and keep reliable backups so future recovery is straightforward.