hello@apluskdesign.com

Troubleshooting SOS

Understand common SOS status messages, what they mean and what to investigate when something needs attention.

Last Updated: 01/10/2026

Version: 1.0

SOS Documentation

Start with the evidenceIf SOS reports that something needs attention, avoid immediately deleting files, reinstalling plugins or changing server settings. Developer Tools can usually tell you where to begin.
SOS – Critical Error Page is designed to operate quietly in the background once it has been configured and tested.If something does not behave as expected, some SOS messages are deliberately cautious. A status may mean that SOS has detected something it does not own or cannot safely change rather than indicating that the website itself is broken.This guide explains common situations, what the available evidence means and what to investigate next.

Start with Developer Tools

If SOS is not behaving as expected, begin with SOS → Developer Tools.

Developer Tools can provide information about:

  • the installed SOS version;
  • the WordPress fatal-error handler;
  • the SOS php-error.php drop-in;
  • the compiled resilience profile;
  • the canonical settings backup;
  • WordPress Recovery Mode;
  • fallback dependencies;
  • WordPress and PHP versions;
  • installation identity; and
  • Geneva connection information where applicable.

Understand SOS Developer Tools →

The SOS drop-in says “Owned and ready”

If Developer Tools reports:

Owned and ready

this is the normal healthy state when SOS is managing its own php-error.php Critical Error Page drop-in.

It means SOS recognises the file as one that belongs to SOS and the drop-in is available for the supported fatal-error path.

If the resilience profile is also present and readable, there may be nothing to troubleshoot.

SOS says “Existing drop-in detected”

WordPress provides a shared php-error.php drop-in location.

Another plugin, developer or custom website configuration may already be using it.

If SOS finds an existing file that it cannot establish belongs to SOS, it deliberately leaves that file alone.

Do not delete the file simply to clear the statusAn existing drop-in may belong to another plugin, developer or custom website configuration. SOS refusing to overwrite it is a protection feature.

Before making changes:

  1. find out what created or manages the existing php-error.php file;
  2. check whether another plugin or custom development relies on it;
  3. take an appropriate backup before changing website files; and
  4. ask the website developer or hosting provider if you are unsure.

Why doesn’t SOS overwrite it?

SOS cannot safely assume that a file belongs to SOS simply because it has the expected filename.

Overwriting an unrelated drop-in could damage functionality belonging to another system.

This ownership safeguard also matters when SOS is deactivated or removed: SOS should manage its own file without deleting a foreign drop-in.

Learn about SOS drop-in ownership →

The resilience profile is missing or unreadable

The resilience profile contains the locally prepared information used by the SOS Critical Error Page.

A healthy installation should be able to report:

Present and readable

If Developer Tools instead reports that the profile is missing or cannot be read:

  1. open the main SOS settings screen;
  2. review the current Critical Error Page configuration;
  3. save the SOS settings again;
  4. return to Developer Tools; and
  5. check the resilience profile status again.

If the problem remains, there may be a filesystem or hosting restriction preventing SOS from preparing or reading its local resilience information.

Resolve the status before further testingDo not repeatedly run the controlled fatal test while the expected resilience profile is unavailable.

The profile date does not reflect my latest changes

If you have changed your Critical Error Page but Profile last compiled does not reflect the latest saved configuration, first confirm that the SOS settings were successfully saved.

Then refresh Developer Tools and review the profile status again.

The emergency experience should use the latest successfully prepared SOS configuration rather than unsaved changes in the administration interface.

The canonical settings backup is missing

On a healthy installation, Developer Tools may report:

Present

If the expected SOS settings backup is unavailable, save the current SOS configuration again and review the status.

If the problem persists, investigate whether the website can write the files required by SOS.

Hosting permissions, filesystem restrictions or security software can sometimes prevent a plugin from managing files it legitimately owns.

The controlled fatal test does not show my SOS page

If the controlled fatal test does not display the expected Critical Error Page, stop before repeatedly triggering it.

Check Developer Tools for:

  • the SOS drop-in status;
  • the compiled resilience profile status;
  • the Recovery Mode status;
  • the current WordPress and PHP environment; and
  • any status indicating that an existing drop-in is already present.

If SOS does not own the active php-error.php drop-in, its Critical Error Page may not be the page used by the supported WordPress error path.

Review Test SOS Safely →

The test page appears, but my changes are missing

If the Critical Error Page appears but contains older information, return to the SOS settings and confirm that your latest changes were saved.

Then review Profile last compiled in Developer Tools.

Run another controlled test only after confirming that the current resilience profile has been prepared successfully.

The normal website does not return after the test

The SOS controlled fatal test is intended to affect the controlled test request rather than deliberately leave the website in a failed state.

If your normal website or WordPress administration area does not return afterwards, do not assume SOS is necessarily the cause.

Investigate the website as you would any other WordPress problem.

Useful evidence can include:

  • WordPress Recovery Mode information;
  • PHP error logs;
  • hosting logs;
  • recent plugin or theme changes;
  • recent WordPress updates; and
  • other errors reported by the hosting environment.

If necessary, contact your hosting provider or website developer.

Recovery Mode says “Preserved”

If Developer Tools reports:

Preserved — WordPress remains responsible

this is the intended state.

SOS does not replace WordPress Recovery Mode.

WordPress remains responsible for the underlying fatal-error handling and its administrator-facing recovery mechanisms.

SOS looks after the visitor experience. WordPress looks after the error.

WordPress Recovery Mode & SOS →

Geneva says “Not connected”

If Developer Tools reports:

Not connected

and:

Last check-in: Never

this is not an SOS error.

Geneva is optional. If you have never chosen to connect SOS, these are valid informational states.

The core Critical Error Page can continue to work without Geneva.

SOS cannot connect to Geneva

If you deliberately choose to connect but the connection does not complete successfully:

  1. review the Geneva status shown in Developer Tools;
  2. check the most recent HTTP status where available;
  3. confirm that the website can make normal outbound HTTPS requests;
  4. check whether hosting or security restrictions are preventing the request; and
  5. allow a temporary network or service problem to clear before trying again.
The Critical Error Page remains independentA Geneva connection problem should not make the locally prepared core SOS experience dependent on the remote service.

Manual check-in fails

If Check in with Geneva now fails, review the returned connection and HTTP status information before triggering it again.

The manual check-in is a technical validation control, not something that should need to be repeatedly used during normal operation.

Connecting SOS to Geneva →

Geneva returns an unexpected relationship

Geneva treats the website relationship and the SOS product entitlement as separate concepts.

An independent public website may, for example, have an Independent / Community website relationship while receiving a Free / Community SOS entitlement.

A website already known to Geneva through an authorised managed relationship can retain that existing relationship while still using the appropriate SOS entitlement.

If the website relationship shown appears genuinely incorrect, contact apluskdesign support rather than repeatedly disconnecting and reconnecting the installation.

SOS cannot write or update its files

SOS needs appropriate access to manage files that legitimately belong to SOS.

If the hosting environment prevents WordPress from writing the required files, SOS may be unable to prepare or update parts of its resilience system.

Possible causes can include:

  • filesystem permissions;
  • hosting security restrictions;
  • ownership or permission differences after a migration;
  • security software preventing file operations; or
  • server configuration.
Do not change permissions indiscriminatelyIf you are not comfortable investigating filesystem permissions, contact your hosting provider or website developer rather than applying broad permission changes simply to make an error disappear.

What happens when SOS is deactivated?

Deactivating a WordPress plugin is intended to stop that plugin’s active functionality.

SOS should withdraw the components it owns as part of its normal lifecycle rather than leave an active visitor-facing integration behind indefinitely.

If SOS is subsequently reactivated, it can prepare its required resilience components again.

What happens when SOS is uninstalled?

Uninstalling SOS is intended to remove SOS-owned plugin data and files.

SOS should not delete an unrelated php-error.php file that it does not own.

Should I reinstall SOS to fix a problem?

Not as the first troubleshooting step.

Reinstallation can sometimes hide useful evidence about the original problem.

Start with Developer Tools, the relevant SOS status and the website’s normal WordPress and hosting evidence.

Reinstall only when there is a clear reason to believe the SOS plugin files themselves are incomplete or damaged.

Check the error log

If the problem appears to involve PHP or WordPress itself, the server or PHP error log can provide useful evidence.

Look at the time the problem occurred and identify which file or component the error actually references.

Correlation is not necessarily causeDo not assume that an error appearing while you are testing SOS was caused by SOS. A WordPress website can contain many plugins, a theme and server-level software capable of generating their own errors.

Where possible, establish:

  • the timestamp;
  • the file or component named in the error;
  • the PHP error type;
  • whether the issue can be reproduced; and
  • whether it occurs specifically in the SOS request or elsewhere on the website.

What information should I provide to support?

When contacting apluskdesign about an SOS problem, useful information can include:

  • the SOS version;
  • WordPress version;
  • PHP version;
  • the relevant Developer Tools status;
  • what you expected to happen;
  • what actually happened;
  • whether the problem can be reproduced; and
  • relevant error-log information with sensitive information removed.
Do not send credentialsDo not send WordPress passwords, hosting passwords, database credentials, FTP or SFTP passwords, API secrets, private keys or other sensitive access information when making an initial support request.

Email support@apluskdesign.com if you need help with SOS.

SOS Support & Security →

Still not sure what the status means?

Not every unfamiliar status indicates a failure.

SOS deliberately distinguishes between:

  • a healthy component;
  • an informational state;
  • something SOS does not own;
  • an optional service that has not been connected; and
  • a genuine condition that needs investigation.

Developer Tools should therefore be read as operational evidence rather than as a simple list in which every value must be green.

Read the status in contextFor example, Geneva: Not connected can be completely normal, while an unreadable resilience profile deserves investigation before relying on the emergency experience.

A sensible troubleshooting order

If you are unsure where to begin, use this order:

  1. Review the relevant status in SOS → Developer Tools.
  2. Confirm that your current SOS settings have been saved.
  3. Check whether the resilience profile is present and readable.
  4. Check whether SOS owns the active Critical Error Page drop-in.
  5. Review the WordPress and PHP environment shown by Developer Tools.
  6. If the problem involves Geneva, review the connection and HTTP status separately.
  7. If the problem involves WordPress or PHP, review the appropriate error logs.
  8. Use the controlled fatal test only when the installation is ready to be tested.
  9. Contact support if the available evidence does not explain the problem.

This approach preserves useful evidence and avoids making unnecessary changes while you are still trying to understand what happened.

Continue exploring

Where next?

Technical

Developer Tools

Understand the operational statuses and technical information available for your SOS installation.


Developer Tools →

Test

Test SOS Safely

Use the controlled fatal test to validate your Critical Error Page without deliberately breaking WordPress.


Test SOS →

Support

Support & Security

Find out how to get help with SOS or report a potential security concern to apluskdesign.


Get support →

Call apluskdesign