Hosting panel
Lets us inspect files, PHP versions, logs, databases, backups, resource limits and other essential settings.
500 error, Critical Error, white screen, broken plugin, database, access or configuration failure. With hosting access, we investigate the cause to recover and stabilize the environment.
A visible error may originate in a plugin, theme, PHP version, memory, permissions, database, server, cache, incomplete update or custom code. Fixing only the symptom can hide the cause and create another failure later.
First we understand what broke. Then we decide what needs to change.
WordPress Rescue is a technical recovery and stabilization intervention. We work from evidence: logs, files, databases, configuration and recent environment history whenever those are available.
In many incidents WordPress itself is unavailable, so a wp-admin user alone may not be enough.
Lets us inspect files, PHP versions, logs, databases, backups, resource limits and other essential settings.
May be required to inspect, isolate, replace or recover files when the administration panel does not respond.
Connection failures, corrupted tables or administrator users may require direct MySQL/MariaDB access or an equivalent tool.
When available, terminal access can accelerate logs, permissions, WP-CLI and controlled operations.
The form is for triage only. After the initial review, RADIAL will explain which accesses are actually required and the appropriate channel for sharing them.
The symptoms below are common, but the actual cause is confirmed only after diagnosis in the environment.
The browser shows a 500 error and the website or wp-admin stops loading.
We inspect logs, PHP, .htaccess, plugins, theme, memory, permissions and recent changes to isolate the source.
“There has been a critical error on this website” appears after an update, installation or change.
We enable safe diagnostics, identify the component generating the exception and define rollback, correction or replacement.
The site loads blank without a clear error message.
We check fatal errors, memory, PHP compatibility, theme, plugins, cache and premature code output.
The public site may load, but the admin loops, blocks the user or returns an error.
We inspect authentication, cookies, URLs, permissions, users, database, security plugins and server settings.
An update or installation breaks pages, checkout, forms or the whole site.
We isolate the plugin without relying on wp-admin, inspect dependencies and PHP version, and assess rollback, correction or replacement.
Layout disappears, functions break or the site stops after a theme change or update.
We inspect parent theme, child theme, functions.php, templates, dependencies and changed files to recover the visual layer safely.
WordPress shows “Error establishing a database connection” or loses access to content and settings.
We validate database service, credentials, host, privileges, wp-config.php, server capacity and table integrity.
Tables return errors, content disappears, queries fail or WordPress behaves inconsistently.
We map the extent of corruption, assess backups, perform viable repairs and rebuild structures when technically possible.
Redirects, unknown files, strange users, spam, browser blocks or security alerts.
We investigate changed files, users, persistence, vulnerable plugins and entry points; remove identified threats and recommend hardening.
WordPress, a plugin, theme or PHP is updated and features stop working immediately or shortly afterward.
We compare versions, logs and dependencies, recover a stable combination and plan the correct update when necessary.
The first technical hour is used for diagnosis and initial intervention. If the incident can be resolved in that period, the service may end there. If the failure requires more work, we explain the situation and estimate the next steps before continuing.
Classification is confirmed after triage. The values below are reference hourly rates for WordPress Rescue.
Common failures with a relatively localized cause and low reconstruction risk.
Problems involving multiple layers or requiring server and compatibility investigation.
Incidents with high risk, integrity loss or partial technical reconstruction.
Minimum billing of 1 technical hour to begin diagnosis.
After the first hour, continuation may be billed in 30-minute increments.
If diagnosis indicates a larger reconstruction project, we present a separate scope before proceeding.
Licenses, third-party services, infrastructure, migration or external resources are not included in the technical hour unless expressly stated.
The process is technical, but communication should remain simple.
You provide the website address, visible symptoms and which accesses are available.
We request only the accesses required to investigate the incident safely.
When possible, we verify backups or create a copy before higher-risk changes.
Logs, files, database, versions and settings help locate the actual cause.
We apply the appropriate intervention: isolation, rollback, repair, replacement or technical reconstruction.
We validate operation and indicate updates, security, backup or changes needed to reduce recurrence.
If the incident reveals a technically unviable structure, we separate recovery from rebuilding so scope and expectations remain clear.
Restore operation and address the identified cause with the smallest coherent intervention.
Correct risks directly related to the incident and indicate what should be updated or reorganized.
When database, code or architecture do not allow safe recovery, a separate rebuild project may be recommended.
Yes. Real recovery usually requires hosting-level access. wp-admin alone may not be enough, especially when WordPress itself is unavailable.
We can triage, but recovery may be limited. If the issue is PHP, files, database, permissions or server-related, hosting access must be obtained from the provider or technical owner.
No. Never send passwords through the diagnosis form. After triage, we explain what credentials are required and how to share them.
A 500 error is a generic symptom. Many cases are simple, but others involve server, database or custom code. Diagnosis determines the cause and recovery feasibility.
We can still investigate and attempt recovery of the current environment. However, no backup increases risk and may limit options, especially with database corruption, compromise or missing files.
We can work with different providers as long as the environment provides enough access and tools for diagnosis. Provider restrictions may limit some interventions.
Yes, as a high-complexity incident. Work may include identifying and removing malicious files, suspicious users and visible vectors, plus hardening recommendations. No internet-connected environment can be promised absolute invulnerability.
It depends on the cause. A broken plugin may be fast; database corruption or malware requires deeper work. The first hour exists to turn a symptom into a technical diagnosis.
Yes. Technical diagnosis is performed even when the conclusion is that recovery is not safe or economically reasonable. We explain alternatives before any additional project.
Only when that is part of a safe solution. Updating everything indiscriminately during an incident can create new conflicts. We stabilize first, then plan required updates.
Yes, but migration is a different scope. If the current infrastructure contributes to the issue, we can evaluate migration after stabilizing or preserving what is recoverable.
Not as standard scope. Rescue is recovery and stabilization. Redesign, new pages, e-commerce, integrations and evolutionary development are separate projects.
You do not need to know the technical name of the problem. Tell us what you see, when it started and what changed recently, if you know.
Do not send passwords through this form.
RADIAL will request the necessary accesses only after initial triage.