Logs, audit history and incident records

Prerequisites and authority

Assign an operator and an authorized technical owner. Data-replacing recovery and updates require a maintenance window, preserved recovery point and known target.

Build a useful operational timeline

Audit logs record administrative actions, system operations record background runs, application logs record technical execution and router/provider logs record external behavior. None is a complete timeline alone.

Start from the incident timestamp and target identifiers. Narrow logs to the relevant period and capture errors before restarting. Record timezone explicitly when comparing host, database, provider and RouterOS timestamps.

From the installed Docker directory, source-based diagnostic examples are:

docker compose --env-file ../.env -f compose.release.yaml ps
docker compose --env-file ../.env -f compose.release.yaml logs --since 30m --tail 200 api

Replace the interval with the actual incident window. Logs can contain personal data or secrets, so inspect/redact before sharing. Avoid dumping the entire resolved Compose configuration or environment.

Connect the customer/payment/subscription/router identifiers to the associated operations. Distinguish an initial failure from later recovery, and record the action that produced the repair.

Do not erase logs or audit records merely because the incident is resolved. Apply the approved retention policy and access controls. Preserve incident evidence separately when necessary.

Use the downloadable incident record for root cause, corrective action, verification and permanent follow-up. A restart without a known cause should remain an unresolved recurrence risk.

Related guides

Related guides: Health checks, background services and workers, Back up BryanNet and validate backups, Restore BryanNet safely, Product updates, compatibility and rollback, Daily weekly and monthly operator checklists.