How-to guide
Operate a running Signals
Change a setting and reload with no restart, pause and resume collection, and stop and start the daemon — the day-2 tasks for a Signals install that is already collecting.
Day-2 tasks for a Signals daemon that is already installed and collecting: change a setting, pause and resume collection, and stop and start the service. For the settings themselves see Signals configuration.
The examples use the control API on http://localhost:8081 with a bearer
token; substitute your own API token (the value of SIGNALS_API_TOKEN /
SIGNALS_API_TOKEN_FILE, or the strong token Signals generated at startup).
Change a setting
There are two kinds of setting, and they take effect differently.
Config-file settings — reload, no restart
Settings in signals.yaml (targets, retention_days, poll_interval,
target_timeout, query_timeout, per-target fields, …) are hot-reloadable.
Edit the file, then tell the running daemon to re-read it:
curl -X POST http://localhost:8081/reload \
-H "Authorization: Bearer <token>"
The daemon re-reads its config with no downtime and no lost collection
history. Sending SIGHUP does the same:
kill -HUP "$(pgrep -x signals)"
Confirm the change with the status endpoint (for example, a newly added target appears immediately):
curl -s http://localhost:8081/status -H "Authorization: Bearer <token>"
Startup settings — change the environment, then restart
Settings supplied as environment variables (SIGNALS_*, such as
SIGNALS_LISTEN_ADDR, SIGNALS_POLL_INTERVAL, SIGNALS_API_TOKEN,
SIGNALS_METRICS_ENABLED) override the file and are read at startup.
Change the environment and restart the service (see below); a reload does
not pick these up.
Pause and resume collection
Stop running collection cycles without taking the daemon down — the API stays reachable and no data is lost:
curl -X POST http://localhost:8081/collect/pause -H "Authorization: Bearer <token>"
curl -X POST http://localhost:8081/collect/resume -H "Authorization: Bearer <token>"
Equivalently with the CLI:
signalsctl pause
signalsctl resume
Use this for a maintenance window on a monitored database, or to hold collection while you reconfigure.
Stop and start the service
Stopping the daemon preserves the local snapshot store; collection resumes from where it left off on the next start.
Container:
docker stop signals
docker start signals
# or, in a Compose project:
docker compose stop signals
docker compose start signals
systemd (see Install and run Signals for the unit):
sudo systemctl stop signals
sudo systemctl start signals
sudo systemctl restart signals # apply an environment change
To enable config reload through systemd, add
ExecReload=/bin/kill -HUP $MAINPID to the unit, then
sudo systemctl reload signals.
Quick reference
| Goal | Command |
|---|---|
| Reload config file (no restart) | POST /reload (or SIGHUP) |
| Pause / resume collecting | POST /collect/pause · /collect/resume (signalsctl pause/resume) |
| Stop / start the daemon | docker stop/start · systemctl stop/start |
| Apply an environment change | restart the service |
| Check current state | GET /status (signalsctl status) |