Emergency: Database Unavailable

Use this file when PostgreSQL is not running, reports unhealthy, or database-backed services fail together.

Protect data first

• Do not delete or recreate the PostgreSQL named volume.
• Do not run a restore or migration command outside the packaged startup path.
• Do not edit assessment, session, evidence, scoring, or audit records manually.
• Record the incident start time in UTC and stop user activity at the customer edge when continued writes could worsen the incident.

Collect state

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

Then capture the migration container history:

./scenariox logs migrate

A migration failure and a database runtime failure require different investigation. Preserve both outputs.

Check host conditions

Confirm without modifying data:

• Docker Engine is running.
• The host filesystem containing Docker data is mounted and has free space.
• The PostgreSQL container has not been replaced with a different release configuration.
• .env still contains the same database names, users, and generated passwords used at installation.

Do not paste .env or database URLs into an incident ticket.

Attempt a reversible restart

If the host filesystem is healthy and logs show a transient container failure rather than corruption or migration failure:

./scenariox restart postgres
./scenariox status
./scenariox health
./scenariox logs postgres

Do not repeatedly restart PostgreSQL when logs indicate corruption, failed migration, or storage errors.

Escalate

Preserve the host and named volumes. Escalate with the UTC timeline, release identity, disk condition, health output, migration logs, and redacted PostgreSQL logs.

Package-native backup, backup verification, restore, and rollback are not available in Self-Hosted V1. Do not claim data recovery until a reviewed recovery procedure has verified both database records and required object storage.