Reference
signalsctl CLI
A complete listing of the two Signals binaries and every subcommand and flag they accept. The signals daemon runs collection and serves the local API; the signalsctl client drives it and runs offline diagnostics.
signals (daemon)
The long-running collector. It loads its configuration, opens the local store, runs the collection loop, and serves the management API that signalsctl talks to.
Synopsis
signals --config <path>Flags
--config <path>— path to the configuration file. When empty, the loader falls back to the lookup order below.
Configuration lookup order
The first existing file wins:
- the path given to
--config /etc/signals/signals.yaml./signals.yaml
Reloading
A running daemon re-reads its configuration without a restart on either a SIGHUP signal or a POST /reload API request. The new config is loaded and validated before it is applied; if loading or validation fails, the reload is rejected and the daemon keeps running on the previous configuration.
# Start the daemon
signals --config /etc/signals/signals.yaml
# Reload after editing the config, in place
kill -HUP "$(pgrep -f '^signals ')"signalsctl (client)
The command-line client. Most subcommands call the daemon's HTTP API; doctor and connect instead read the config and probe targets directly, so they run without a live daemon.
Global flags
These persistent flags apply to every subcommand:
--api-addr <url>— Signals API address. Defaulthttp://127.0.0.1:8081.--api-token <token>— API bearer token. Defaults to the$SIGNALS_API_TOKENenvironment variable.
signalsctl version
Print version, commit, and build-date information for the client.
signalsctl versionsignalsctl status
Show collector status as JSON. Issues a GET /status request to the daemon. Takes no flags beyond the global ones.
signalsctl statussignalsctl collect
Collection management. Parent command for now, pause, and resume.
collect now
Trigger an immediate collection cycle.
--force— bypasssignals.min_snapshot_intervalfor this one cycle. Without it, a target collected inside the interval window is skipped.
signalsctl collect now
signalsctl collect now --forcecollect pause
Pause collection for one target, or for every enabled target when --target is omitted. A paused target stays paused until collect resume is run; pause state is in-memory only, so a daemon restart resumes all targets.
--target=<name>— target name. Empty means every enabled target.--reason="…"— operator-supplied reason (≤ 256 characters), recorded in the audit log.
signalsctl collect pause --target=prod-primary --reason="planned maintenance"collect resume
Resume collection for a paused target, or for every enabled target when --target is omitted. Resume clears the paused state and resets the consecutive-failure counter. Unknown target names are rejected.
--target=<name>— target name. Empty means every enabled target.
signalsctl collect resume --target=prod-primarysignalsctl export
Export collected data as a ZIP archive. With no flags, the export contains only the latest completed snapshot per active target — the unit downstream consumers ingest as a single analysis. The selector flags widen or narrow that scope.
--output <file>(-o) — output file path. Defaults tosignals-export-<timestamp>.zip.--all— include every snapshot in local storage (forensic full-history). Mutually exclusive with--snapshot-id.--snapshot-id <id>— include exactly one snapshot by id. Mutually exclusive with--all.--since <RFC3339>— include snapshots collected at or after this timestamp.--until <RFC3339>— include snapshots collected at or before this timestamp.--target-id <int>— narrow the export to a single target.0means all targets.
# Latest snapshot per target (default)
signalsctl export
# Everything, to a named file
signalsctl export --all -o forensic.zip
# A single snapshot
signalsctl export --snapshot-id 42
# A time window for one target
signalsctl export --since 2026-06-01T00:00:00Z --until 2026-06-08T00:00:00Z --target-id 3--all and --snapshot-id cannot be combined; supplying both is rejected as a usage error.signalsctl doctor
Run read-only operator pre-flight checks against the config and targets. Reads the config from disk and probes targets directly — it does not call the daemon API. Exits 0 when every check is OK, 1 when any check fails, and 2 on usage errors (such as an unknown --check name).
--config <path>— path to the config file.--check <name>— run only the named checks, e.g.--check=C1,C3.--json— emit a JSON report instead of human-readable text.
The checks:
C1 config_valid— config parses and passes strict validationC2 store_writable— the SQLite store path is writableC3 target_reachable— each enabled target accepts TCPC4 role_safe— each reachable target's role is not superuser, replication, or bypassrlsC5 collector_prerequisites— each target's enabled collectors are classified (available / missing / unsupported)C6 snapshot_freshness— each target's latest snapshot is within 2× the poll interval
signalsctl doctor --config /etc/signals/signals.yaml
signalsctl doctor --check=C1,C3
signalsctl doctor --jsonsignalsctl connect
Connection diagnostics. Parent command for test and auto.
connect test
Test PostgreSQL connectivity and classify any failure into one of ok, dns, tcp, tls, auth, startup, role, password_resolve, or config. Exits 0 when every attempt is OK, 1 when any fails, and 2 on usage errors.
Modes:
signalsctl connect test— test every enabled target in the configsignalsctl connect test <target-name>— test one target from the configsignalsctl connect test --dsn "…"— test an ad-hoc DSN without a config
Flags:
--config <path>— path to the config file (ignored when--dsnis supplied).--dsn "…"— ad-hoc DSN fields as space-separatedkey=valuepairs. Mutually exclusive with a positional target name.--json— emit a JSON report instead of human-readable text.
Recognised --dsn fields: host, port, dbname, and user are required; sslmode (default prefer), password_env, password_file, and pgpass_file are optional.
signalsctl connect test
signalsctl connect test prod-primary
signalsctl connect test --dsn "host=db port=5432 dbname=app user=signals sslmode=require" --jsonconnect auto
Guided onboarding for a single PostgreSQL target. Auto-detects the cloud platform and ambient identity, selects an auth method, resolves the credential without printing it, runs the connection diagnostic over verify-full, validates the role is read-only, and prints a ready-to-use, secret-free target config block on success. The default is dry-run (print only). Exits 0 on a verified connection, 1 on a fixable gap, and 2 on usage errors.
--host <host>— target host (required).--port <int>— target port. Default5432.--dbname <db>— target database name.--user <role>— role to authenticate as (required).--auth-method <method>— override detection:password,aws_rds_iam,azure_entra,gcp_cloudsql_iam,secret_store, ormtls.--write <path>— append the verified target block to this config file. Without it, the command is dry-run.
# Dry-run: detect, connect, verify, and print a config block
signalsctl connect auto --host db.example.com --user signals --dbname app
# Append the verified block to a config file
signalsctl connect auto --host db.example.com --user signals --dbname app \
--auth-method aws_rds_iam --write /etc/signals/signals.yamlconnect auto; the emitted target block is credential-free.