hello@apluskdesign.com

SOS Developer Tools

Understand the operational information SOS provides about your Critical Error Page, resilience profile, WordPress environment and optional Geneva connection.

Last Updated: 01/10/2026

Version: 1.0

SOS Documentation

Operational information for SOSDeveloper Tools helps administrators and developers confirm that important SOS components are available, understand what the emergency experience depends on and investigate a status that needs attention.
SOS Developer Tools provides additional technical information about the current SOS installation.You do not need to understand every row in Developer Tools in order to use SOS.For most users, SOS can simply remain prepared in the background after configuration and testing.Developer Tools becomes particularly useful when you want to validate the installation, understand how SOS is operating or investigate something that does not look right.

Open Developer Tools

From your WordPress administration area, go to SOS → Developer Tools.

The information shown reflects the current SOS installation and WordPress environment.

Operational status

The main status area provides an overview of the components involved in the SOS emergency visitor experience.

On a healthy installation, the information helps confirm that SOS is prepared for its supported fatal-error path.

SOS Developer Tools
Review the current fallback state, environment, Recovery Mode relationship and Geneva connection,
and manually check in with Geneva when connected.

SOS version

This shows the version of SOS currently installed on the website.

The version can be useful when checking documentation, requesting support or confirming that an update has been installed successfully.

Fatal handler

SOS is designed to preserve WordPress Core’s responsibility for fatal-error handling.

On a healthy installation, Developer Tools can report:

WordPress Core

This confirms that SOS has not attempted to replace WordPress’s underlying fatal-error handling system.

SOS php-error.php drop-in

WordPress supports a special php-error.php file that can be used as part of its fatal-error handling process.

SOS can manage its own drop-in at this location when it is safe to do so.

A healthy SOS-managed installation may report:

Owned and ready

This means SOS recognises the Critical Error Page drop-in as one that belongs to SOS and it is available for the supported emergency experience.

Existing drop-in detected

If Developer Tools reports Existing drop-in detected, SOS has found a php-error.php file that it cannot establish belongs to SOS.

Do not delete an unfamiliar drop-in automaticallySOS deliberately does not overwrite, modify or remove a file simply because it occupies the same WordPress location. The file may belong to another plugin, developer or custom website configuration.

If this status appears, investigate the existing file before making changes.

Troubleshoot an existing php-error.php drop-in →

Compiled resilience profile

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

A healthy status may report:

Present and readable

This means the prepared profile is available to the SOS emergency experience.

The profile allows the visitor-facing page to use information prepared while WordPress is operating normally rather than depending on normal website content at the point of failure.

Profile last compiled

This shows when SOS most recently prepared the resilience profile.

If you have recently changed and saved your Critical Error Page settings, this information can help confirm that the prepared profile has subsequently been refreshed.

Canonical settings backup

Developer Tools can report whether the canonical SOS settings backup is available.

A healthy installation may report:

Present

This forms part of the local resilience information maintained by SOS.

If the expected backup is missing, review the SOS configuration and any other status information before relying on the installation as fully prepared.

Learn how the SOS resilience profile works →

Recovery Mode

Developer Tools shows the relationship between SOS and WordPress Recovery Mode.

On a healthy installation you may see:

Preserved — WordPress remains responsible

This is the intended SOS architecture.

SOS provides the visitor-facing Critical Error Page while WordPress remains responsible for its own fatal-error detection and administrator-facing recovery mechanisms.

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

Learn more about WordPress Recovery Mode & SOS →

Fallback dependencies

Developer Tools can explain what the prepared SOS emergency experience requires during fallback.

These statuses help you understand the deliberate independence built into the Critical Error Page.

Database required during fallback

A healthy SOS configuration should report:

No

This does not mean SOS protects or repairs the WordPress database.

It means the prepared visitor-facing Critical Error Page does not need to retrieve its configuration from the database at that moment.

Theme required during fallback

A healthy SOS configuration should report:

No

SOS does not need to load the active WordPress theme in order to construct its prepared Critical Error Page.

This is why the emergency experience is intentionally simpler than your normal website.

Remote API required during fallback

A healthy SOS configuration should report:

No

The core Critical Error Page does not require a remote API in order to render.

This includes Geneva: connecting SOS to Geneva is optional and does not turn the remote service into a dependency for the emergency page.

Three useful checksDatabase: No. Theme: No. Remote API: No. Together, these statuses help explain how SOS reduces unnecessary dependencies during its supported fallback experience.

Environment information

Developer Tools displays basic information about the environment in which SOS is currently operating.

This can include:

  • the current environment designation;
  • the WordPress version; and
  • the PHP version.

This information can be useful when troubleshooting compatibility or providing technical information to support.

Installation identity

SOS maintains an installation identity that can help distinguish the current SOS installation where supported product functionality requires it.

This identity describes the installation rather than individual website visitors.

It can also help an optional Geneva connection recognise the same installation consistently across repeated check-ins.

Not a visitor identifierAn SOS installation identity should not be confused with visitor analytics, a visitor cookie or a behavioural tracking identifier.

Learn more about SOS Privacy & Data →

Geneva connection status

If your SOS installation uses the optional Geneva connection, Developer Tools can show technical information about the current relationship.

The information available can include:

  • Geneva connection status;
  • production or configured endpoint information where applicable;
  • installation identity;
  • last check-in time;
  • the most recent HTTP status;
  • the returned SOS entitlement;
  • the website relationship returned by Geneva; and
  • the most recent Geneva status message.

Not connected

A new independent SOS installation may report:

Not connected

and:

Last check-in: Never

These are informational states rather than errors.

Geneva is optional and SOS does not need to connect before its core Critical Error Page can work.

Connected

After an authorised administrator deliberately connects SOS to Geneva, Developer Tools can report the current connection and information returned by the service.

A healthy connected installation can report its current relationship, entitlement and successful connection evidence.

Learn more about Connecting SOS to Geneva →

Check in with Geneva now

For an already-connected installation, Developer Tools can provide a Check in with Geneva now action.

This allows an authorised administrator or developer to deliberately perform a Geneva check-in and inspect the resulting connection status.

It is primarily a technical validation and troubleshooting control.

Not a routine taskA healthy Geneva connection should not require you to manually check in every time you use SOS.

If you use the manual check-in control, review the resulting status rather than repeatedly triggering the action.

Controlled fatal test

Developer Tools provides the controlled fatal test used to confirm that the prepared SOS Critical Error Page is available.

The test deliberately invokes the supported fatal-error path for a controlled request.

It provides a safer validation route than deliberately damaging WordPress, a theme or a plugin to create a real error.

After running the test, you should be able to:

  • view your configured Critical Error Page;
  • check the visitor-facing presentation and actions; and
  • return to the normal website and WordPress administration area.
Use the controlled testDo not deliberately introduce errors into production WordPress files simply to test the SOS Critical Error Page.

Learn how to Test SOS Safely →

What should I look for?

You do not need every row in Developer Tools to contain the same wording on every installation.

Instead, look for anything that clearly indicates that a component is unavailable, unreadable, conflicted or needs attention.

For a typical healthy SOS installation, the important principles are:

  • WordPress remains responsible for fatal-error handling and Recovery Mode;
  • the SOS Critical Error Page drop-in is available where SOS owns it;
  • the resilience profile is present and readable;
  • the prepared fallback does not depend on the active theme, database or remote API; and
  • optional Geneva information accurately reflects whether you have chosen to connect.

If a status does not look right

Do not immediately delete files or repeatedly reinstall SOS simply because a status is unfamiliar.

Some statuses are deliberately cautious.

For example, Existing drop-in detected is not evidence that SOS is broken. It means SOS has found a file at the shared WordPress drop-in location and is refusing to assume ownership of it.

Troubleshooting SOS →

Information useful for support

If you need help with SOS, some Developer Tools information may be useful when describing the problem.

Useful non-sensitive information can include:

  • the SOS version;
  • WordPress version;
  • PHP version;
  • the drop-in status;
  • the resilience profile status;
  • Recovery Mode status; and
  • the current Geneva status where the issue relates to Geneva.
Do not send credentialsDo not send WordPress passwords, hosting credentials, database passwords, private keys or other sensitive access information when making an initial support request.

If you need help understanding a Developer Tools status, email support@apluskdesign.com.

Continue exploring

Where next?

Troubleshoot

Troubleshooting SOS

Investigate drop-in, resilience-profile, testing and Geneva statuses that need attention.


Troubleshoot →

Understand

How SOS Works

Understand the resilience architecture behind the statuses shown in Developer Tools.


How SOS Works →

Test

Test SOS Safely

Use the controlled fatal test to confirm your Critical Error Page and visitor experience are working as expected.


Test SOS →

Call apluskdesign