Emergency: Platform Unavailable

Use this file from the extracted release directory when the ScenarioX web interface cannot be reached.

Protect evidence first

• Do not remove named volumes, .env, keys, or the release directory.
• Do not run a purge, restore, or undocumented database command.
• Record the incident start time in UTC and the affected recruiter, candidate, and runtime URLs.
• Preserve any trace, session, assessment, or candidate identifier already visible to the operator.

Collect state

./scenariox version
./scenariox status
./scenariox health
./scenariox logs

Save terminal output in the customer incident system. Review it for secrets before sharing outside the authorized operations team.

Classify the failure

• If configuration validation fails, correct only the named configuration or key-file issue and run ./scenariox preflight.
• If one service is not running or unhealthy, inspect that named service with ./scenariox logs <service>.
• If PostgreSQL is unavailable, continue with Database unavailable.
• If workspace or evaluation services are affected, continue with Workspace or evaluation failure.

Attempt a reversible restart

When logs show no migration, storage, or data-integrity failure, restart the affected service and verify readiness:

./scenariox restart <service>
./scenariox status
./scenariox health
./scenariox logs <service>

Use ./scenariox restart without a service name only when the entire application requires restart and dependencies are available.

Escalate

Escalate with:

• UTC incident timeline
• ./scenariox version output
• affected URLs and service names
• health output
• redacted relevant logs
• last known successful operation

Automated support bundles, backup, restore, rollback, and purge are not available in Self-Hosted V1.