Buttons runs as a set of separate processes working together, watched over by a supervisor that keeps them alive. Most day-to-day health information shows up on the Dashboard; the full picture, and the only place to restart an individual process, is Settings → Services.
The Home navigation icon shows a count badge whenever there are standing warnings: amber when they're all warnings, red when at least one of them is an error.
A dedicated System Warnings card appears on the Dashboard only when there's a standing issue in one of three categories: a process problem, a high-availability problem, or a browser-compatibility problem. Each entry is labeled by category: Service (a process issue), HA, or Browser, followed by the specific warning and its message, and is shown in amber for a warning or red for an error. Only Service (process) warnings carry a restart control here, and clicking it restarts that process immediately, with no confirmation step.
Issues with surfaces, workflows, and NMOS nodes don't get a dedicated warnings card. Instead, the affected item shows an amber status dot in its own list on the Dashboard, and items with issues sort to the top of their list so they're easy to spot. Connections show their own status in the same way: a green dot when connected, amber while connecting or when the configuration is wrong, and red when the connection is down or has failed.
Check and restart services in Settings → Services#
Open Settings → Services for the full list of running processes. The page is titled High Availability Status in every deployment. In a standalone deployment its description reads Status and control of all running services, and in a high-availability deployment (multiple nodes) it reads Real-time status of all processes across nodes.
A green banner reading System Health: OK / All services are running normally appears when nothing needs attention.
Each service is listed with its Status, its Uptime, and a restart icon under Actions. The status is Running, Starting, Waiting (the process is waiting for another service or for its network port), or Stopped; the legend under the list explains only Running, Starting, and Stopped. An uptime under 30 seconds shows in red, a sign the process has just started or restarted.
To restart a single process, use its restart icon in the row. This takes effect immediately: there's no confirmation dialog and no warning about the interruption it causes, so only restart a process when you're ready for it to briefly go offline. One process is protected from this control: the key-value store (Valkey on macOS/Linux, Garnet on Windows) can't be restarted from here, since too much else depends on it staying up.
The page starts with a card for each node, showing whether it's Ready, its address and versions, and how much of its CPU, memory, and disk is in use. A node taken out of service shows a Cordoned tag.
Below the cards, a grid lists each process that runs as one active copy with backups, with a column per node and a Leader column naming the node where it's currently active. In each cell, P1 to P3 is that copy's priority (1 = highest), followed by its role:
Leader: the active copy.
Standby: ready to take over.
Witness: takes part in choosing the leader only.
Not Responding (amber): its heartbeat is overdue.
Unavailable (red): there's no heartbeat at all.
Under the legend, Load-Balanced Services lists the services that run on every node at once, such as the database and the web server, with each node's status and a Health count of how many copies are running. Any service that runs as a single process appears under Other Services, with the same restart icon as in a standalone deployment.
To restart one copy of a process, open the menu next to its status and choose Restart Pod. Like the restart icon, this happens immediately, without a confirmation.
To take a node out of service, for example before maintenance, open the menu next to its Ready status and choose Cordon & Drain, then confirm. The services running on the node stop and start on the other available nodes. Choose Uncordon from the same menu to bring the node back into service.
Buttons doesn't automatically restart a crashed process for you outside of one specific case: in a high-availability deployment, taking a node offline with Cordon & Drain causes the services that were running on it to start automatically on other available nodes in the cluster. That's a deliberate failover action you take, not an automatic recovery from a crash. Outside of it, a stopped or stuck process stays stopped until you restart it yourself.
A person actively working in the editor doesn't just see an error the moment a service they depend on (the database, for example) becomes briefly unreachable. Buttons keeps the page mounted, including any unsaved form you were editing, and shows a recovery state that blocks interaction and marks visible information as potentially stale while it checks the session and retries in the background, roughly once a second for the first minute and roughly every ten seconds after that. Once the service answers again, Buttons automatically refetches what failed and reconnects any live subscriptions, with no manual reload needed.
If the outage runs past about 20 seconds, a Refresh button also appears on the recovery dialog as a manual fallback, reloading the page immediately rather than waiting for the automatic recovery.
Short interruptions don't bring up the dialog. If the editor's live connection drops and reconnects within about 5 seconds, which also happens routinely when your session token is renewed, nothing is shown. A single request that times out, or an action that fails on a device, makes Buttons check that it's still reachable first. The dialog appears only if that check also fails.
This only covers a genuine, temporary infrastructure problem: a session that's actually expired or been revoked still requires signing in again, and an ordinary error from a specific request doesn't trigger it. Buttons never replays a mutation (an action you tried to submit) on your behalf once recovery completes: if you attempted to save something during the outage, check whether it actually went through before assuming it did.
There's no dedicated "restart everything" control. The only full-system reset is Delete Configuration on the Configuration Data page, which resets the installation to factory settings and restarts the system as a side effect of that reset. It isn't a safe way to simply bounce every process, since it also wipes your configuration. See Export or import Buttons configuration before considering it.
The Home icon shows a badge but there's no System Warnings card.
The issue is likely with a surface, connection, workflow, or NMOS node rather than a process: check each list on the Dashboard for an amber or red status dot.
A service shows Stopped and isn't coming back on its own.
Restart it manually from Settings → Services: outside of node failover during Cordon & Drain, Buttons doesn't restart a stopped process automatically.
The restart icon is unavailable for a service.
The key-value store (Valkey/Garnet) can't be restarted from this page; if it needs attention, that's a deeper intervention outside routine service restarts.
You want to recover from a broad, unclear problem.
Restart the specific process shown as unhealthy rather than reaching for Delete Configuration: that action resets your entire configuration, not just the running processes.
The editor is blocked with a recovery state and won't clear.
Give it time: it retries roughly once a second for the first minute, then roughly every ten seconds. If the underlying service is actually still down, fix that first, see Check and restart services in Settings → Services above.
The Watchdog itself appears to hang, unresponsive, during startup or while stopping every process.
A prior lock-ordering bug in the Watchdog's process manager could deadlock it in either direction; this is fixed. If you still see it on a current version, treat it as a new finding rather than a known issue.
