Open Status
Monitor credentials and secrets

Monitor credentials and secrets

Monitor secret storage, controlled disclosure, and encryption keys.

Monitor configuration can contain secrets: credentials embedded in HTTP and WebSocket URLs, HTTP query-parameter and header values, HTTP request bodies, UDP payloads, API-sequence secret variables, proxy credentials, and custom certificate bundles. This page explains how Status stores and reveals them, and how the deployment administrator manages the encryption keys.

How secrets behave in the console

Status encrypts stored request credentials. The monitor editor and API return the fixed •••••• marker instead of stored values:

  • Saving an edited monitor with the marker in place preserves the existing value.
  • A new monitor or template must provide the real value.
  • The marker covers full-credential fields such as proxy URLs and custom certificate bundles; leaving it in place during an edit keeps the bundle while allowing other settings to change.

Secret values are revealed only where a workflow creates or rotates them:

  • a heartbeat push URL, shown once when the monitor is created or rotated;
  • heartbeat URLs created by an import or template batch, shown and downloadable once;
  • the shared or private worker credentials, shown once at generation;
  • exported monitor packages, which intentionally contain request credentials so they can be restored elsewhere.

Treat export files and copied tokens like credentials: store them in access-controlled locations.

Workers receive decrypted settings only after worker authentication. Monitor failures are scrubbed of credential values before their messages are displayed or stored, so secrets do not appear in the console or diagnostics.

Manage the encryption keys

The deployment administrator controls the key ring that protects stored credentials. Set MONITOR_ENCRYPTION_KEYS to a current-first, comma-separated list:

dotenv
MONITOR_ENCRYPTION_KEYS=2026-07:<base64-32-byte-key>,2026-01:<base64-32-byte-key>

Key IDs may contain letters, numbers, ., _, and -. Every key must decode to exactly 32 bytes, and IDs must be unique. Generate a key with:

Shell
openssl rand -base64 32

When MONITOR_ENCRYPTION_KEYS is absent, the application derives a backward-compatible key from NEXTAUTH_SECRET. Production installations should configure a dedicated key ring: changing NEXTAUTH_SECRET otherwise also changes the derived credential key.

Retain keys used by stored credentials

Keep every key referenced by stored credentials in the key ring, including keys needed by backups. Adding a key does not re-encrypt existing credentials. Losing every key named by a stored credential prevents those request credentials from being decrypted; they must be re-entered.

Related documentation