Lockdowns
A lockdown is Churchill’s terminal containment state. The protected application on the host has been killed and stays dead, across restarts and reboots, until a human clears the lockdown. The state is held by the control plane, so rebooting the host does not clear it. This is by design. See the glossary.
The Lockdowns page is the containment view: which hosts are locked right now, since when and why, and everything that entered lockdown over the last 30 days. Next to the page title you see a count of active lockdowns and how many kills the control plane has sent. The kills figure is a server-wide running total, not a per-host count.
The alarm strip
Section titled “The alarm strip”When at least one lockdown is active, a strip at the top of the page states the count in bold, such as “2 hosts in lockdown”, followed by the names of every locked host. The whole page takes an alarm treatment. If the page looks normal, nothing is locked.
Active lockdowns
Section titled “Active lockdowns”The Active lockdowns table shows one row per locked host:
| Column | Meaning |
|---|---|
| Host | The host’s name, or its ID when no name has been reported. Selecting it opens the host’s detail page. See Host detail. |
| Worst φ | The host’s worst heartbeat-health score. See the glossary. |
| Lockdowns | How many lockdowns are in effect on the host. |
| Cgroup | A frozen pill when the protected application’s control group is frozen, “no” otherwise. |
| Since | When the lockdown was entered. |
| Mode | How the lockdown originated. |
| Actor | Who asserted the lockdown: an operator identity, or the control plane itself when it decided on its own. A dash when no actor was recorded. |
| Reason | Why the host locked down. Long reasons are shortened. Hover to read the full text. |
| Kills | Always a dash. Per-host kill counts are not exported. The server-wide total next to the page title is the only kills figure. |
| Actions | Buttons for this lockdown. See below. |
Since, Mode, Actor, and Reason are joined from the lockdown history. When no history entry matches the host, each shows a dash with the hover note “no lockdown-history entry for this host”.
Each row carries one action button, Evidence, which opens the Evidence page where the events leading up to the lockdown are recorded. See Evidence. Unlocking is a containment action on the host’s enrollment record, so it lives on Fleet and on the host’s detail rail, not here. See Recovering a locked host.
When nothing is locked, the table shows a single line: “no active lockdowns · fleet operating normally”.
Recent history
Section titled “Recent history”The Recent history · last 30 days card lists every lockdown entered in the last 30 days, newest first:
| Column | Meaning |
|---|---|
| Host | The host’s name, falling back to its host ID. Hover it to read the host ID either way. |
| Entered | When the lockdown began (UTC). |
| Exited | When it was lifted. A dash while the lockdown is still active. |
| Duration | How long the lockdown lasted, marked “(ongoing)” while it is still open. |
| Actor | Who asserted the lockdown. A dash when none was recorded. |
| Reason | Why the host locked down. Long reasons are shortened. Hover to read the full text. |
| Resolution | “exited” once the lockdown was lifted, “active” while it is open. |
If nothing has locked in the window, the card reads “No lockdowns entered in the last 30 days.” If the history cannot be fetched, the card reports “Lockdown history unavailable” with a short reason. The active-lockdowns table above still works, but its Since, Mode, Actor, and Reason columns show dashes until the history recovers.
What puts a host in lockdown
Section titled “What puts a host in lockdown”- A fatal detection on the host. Lockdown is the tail of the kill sequence. When Churchill detects tampering, it freezes and kills the protected application, then persists the lockdown so the application cannot come back compromised.
- A denied or expired change. A vetoed change request, or a change window that expires with the change still in place, ends in lockdown for the affected host. Reverting the change before the deadline aborts the window instead, and the application restarts on its old baseline. See Change control.
- Persistent compromise. A host that keeps reporting compromise after receiving a clean deployment is locked. A fresh copy that is already tampered points at a problem below Churchill’s reach.
- Host identity mismatch. A host that reconnects with an identity fingerprint that does not match its enrollment is locked down.
Recovering a locked host
Section titled “Recovering a locked host”Unlocking is an accountable human decision. It never happens automatically. It is entirely a control-plane action: the lockdown lives in the control plane, not in a file on the host, so recovery needs no host access, no file to delete, and no reboot.
- Investigate before you clear. A lockdown means Churchill saw something fatal. The reason is in this page’s Reason column, and the events leading up to it are on the Evidence page. Make sure you understand the cause before bringing the application back.
- Unlock the host. Open the host’s row on Fleet, or its detail page, and select Unlock… in the enrollment actions. Type the host’s client identity and give a reason.
- The host resumes on its own. The enrollment goes back to enrolled and the live session is told to resume normal operation. Nothing on the host is touched and nothing is re-attested by the unlock.
Both directions are recorded. Entering lockdown and clearing it land in the evidence log, and the unlock is written to the lockdown ledger under your operator identity and to the audit chain, with the reason you gave. The full containment-and-recovery story stays auditable.