System monitor: work processes, traces, locks and sessions

What the platform is doing this second, the database work behind it, the locks it holds and who is signed in — and how to stop any of it.

Work Processes, System Traces and Locks are under Platform → Operations → Health, beside the integration, pipeline and workflow health screens; Web & User Sessions is under Platform → Access, beside Users. Each is its own permission, so an operations role can be allowed to watch the system and cancel a runaway query without also being allowed to sign everybody out.

Work Processes

Every request being answered, every background worker (the scheduler, the mailer, process mining, data retention, e-signature sweeps, the estate reporter) and every batch run, on every running container — each tied to the database backend it is using at that moment. Below it, every database connection with its state, what it is waiting on, how long its statement and its transaction have been open, who blocks it, and which request or job sent it.

• Cancel stops the statement that is running now; the request then ends with an error instead of waiting. Tick several rows and use Cancel selected to stop them together.
• On a batch run, Cancel stops it at the next item — no item is abandoned half done — and the run is recorded as cancelled with what it had finished.
• End (on a database backend) closes that connection and rolls back its transaction. Use it for a session sitting "idle in transaction" and holding locks, which Cancel cannot reach because nothing is running.
• Work on another container is cancelled through that container: it acts within ten seconds.
• Every cancel and end asks for a reason, which goes into the audit log with your name.

System Traces

Trace (on any work or backend) opens one process in full: every statement it sent, with the time each took and the rows it returned, the locks it holds and waits for, the chain of sessions in front of it, the sessions queued behind it, and the query plan of what it is running now where that can be shown safely. The System Traces screen lists the slowest and most recent work, and — where the database has pg_stat_statements — the statements that have used the most database time. Values typed by users are never recorded: they are where personal data is.

Locks

Locks being waited for, locks that block somebody, advisory locks (the schema migration lock is named), and batch runs that still say "running". A lock is marked stale when the transaction holding it has sat idle for longer than the threshold you set (five minutes by default), or when no running container claims the batch run — a run whose container stopped will never finish, and its schedule will not run again until it is released.

• Select all stale, then Release selected. PostgreSQL gives a lock back only when the session holding it ends, so Release ends that session and rolls back its transaction.
• A lock that is NOT stale is refused unless you choose Force release — ending a healthy transaction that happens to hold a lock this second is the click that causes the incident it was meant to fix.
• Releasing a stale batch run marks it failed, so its schedule can run again.

Web & User Sessions

Every web session (one per browser or device) and every signed-in person, with what each is doing right now. Switch between By person and By session, filter by name, address or source, and sign out one session, a person's every session, a selection, or everybody except you. Service accounts appear here too, one session per token. Your own session is never ended by a bulk action.