system manager stopped [SQL0065]

The system manager’s reconcile loop ended a life on its own, so nothing is currently spawning or healing the deployment’s workers: partitions go undropped, retention stops moving, schedules stop firing, and the built-in alert checks stop running.

Two things end a life this way. A worker the manager spawned returned a fatal error, which tears down that manager instance and everything it had running; or the manager row could not be claimed after it had been claimed once, which usually means the row was edited or removed while the loop held it.

The loop does not end here. It waits out the backoff on the line’s delay, then claims the row again and rebuilds its workers, so upkeep comes back on its own once the underlying problem is fixed. attempt counts the lives it has lost in a row — a single line is a blip, a climbing attempt is a worker that fails every time it starts.

Read the error attribute first: it names the worker that failed and carries its error. The line is emitted by whichever process holds the manager claim, which may be a sqlstreams manager run process or any consumer, since a consumer runs the deployment’s upkeep unless ClientConfig.DisableManager says otherwise.

A misconfigured deployment fails differently and earlier: if the system has never been registered, or the manager row cannot be read at all, the first Consume, Client.Manager().Run, or SchedulerInstance.Schedule call returns that error instead of logging this one.