The part that watches, and only watches.

Watchtower is the platform's senses. Agents run on each machine, observe it — metrics, health, state, crash and stop events — and report inward. It is the eyes and ears of the system, and it is purely afferent: it observes; it never acts.

That single constraint is what makes it cheap to trust. Sensing changes nothing, so it is the one operation that never needs permission — you don't ask to be allowed to notice something.

Role
Sensing, afferent only
Transport
Agent dials out
Interface
Conversation, over MCP
Substrates
Docker · Linux · Windows

§ 01 / DefinitionWhat Watchtower is

Watchtower is a self-hosted platform for keeping an eye on a fleet of machines — the containers, services, scheduled tasks, and disks across every host you run. A lightweight agent lives on each machine and pushes what it sees to a central hub.

What it deliberately is not is a dashboard you click through. The primary interface is a conversation: you ask an assistant what is wrong, and it reads the fleet's state to answer. The clicking-through-panels model does not scale past a handful of hosts; a question does.

§ 02 / PrincipleSensing, and only sensing

The load-bearing design choice is a subtraction. Watchtower observes and reports — health, state, events, ambient conditions — and it dispatches and executes nothing. Acting on a machine is a separate concern, owned by a separate part of the platform, reached through a separate gate.

The line between sensing and acting is the same line as between ungated and gated. Whether something needs permission is the same question as whether it changes the world.

Keeping the senses strictly afferent buys a clean guarantee: a component that can only observe cannot be tricked into acting. There is no code path from Watchtower to a changed machine, so a compromised or confused sensor's worst case is a wrong reading — never a wrong action. Readings can be cross-checked, weighted by a source's track record, and audited after the fact. That is a far smaller blast radius than a sensor that can also pull triggers.

§ 03 / TransportThe host always dials out

The hub never dials an agent. Every connection is opened by the agent, outward — the agent pushes its metrics and events on its own cadence, and even live streams (log tails, resource stats) travel back down a connection the agent itself opened. Nothing reaches inward to a managed host.

   each managed host                         central
   ┌──────────────────┐                    ┌──────────┐
   │  agent           │ ──push metrics──▶  │          │
   │  · collectors    │ ──push events───▶  │   hub    │
   │  · watchers      │ ◀─pull config────  │          │
   │                  │ ◀═live streams═══  │          │
   └──────────────────┘   (agent-dialed)   └──────────┘
        the host originates every connection — nothing dials in

This matters for where Watchtower can run. Because agents reach out rather than being reached, a host behind a firewall or on a laptop that comes and goes needs no inbound access, no exposed port, no exception. Missing a push is not an error — the next one supersedes it — and if the hub is briefly unreachable, durable events queue on disk and drain when it returns.

§ 04 / InterfaceManaged by conversation

Watchtower exposes its read surface to an assistant over MCP, so the fleet becomes something you interrogate in plain language rather than navigate:

The shape of a real exchange
  • You: "This host has been sluggish — what's wrong?"
  • Assistant: reads the host's diagnostics — CPU pinned at 94%, a container running eighteen hours with no output, last night's backup job failed at 3am because a volume hit 98%.
  • The answer names the cause, not a wall of graphs. The graphs still exist; you just don't have to be the one correlating them.

Everything on this surface is observation. When the same conversation needs to act — kill that container, reclaim that volume — the action does not run through Watchtower. It crosses the platform's authorization gate first, and is carried out by the part of the system whose entire job is doing things carefully. The senses and the hands are different bodies on purpose.

§ 05 / ReflexesFast, local, pre-wired

Not everything should wait for a conversation. Watchtower's hub carries simple local reflexes — a container that crashes, a watched service that stops, a host that goes quiet past its interval — that fire an alert immediately, without troubling the reasoning layer.

Anatomically this is the sensory spinal cord: it relays sensation inward and fires simple reflexes on its own, but it originates nothing and decides nothing. A reflex raises attention; it does not take an action on a machine. Crash and stop detection are event-driven, so the latency between something going wrong and someone knowing is near zero rather than one polling interval.

§ 06 / ScaleOne control plane, many kinds of host

The transport, identity, audit, targeting, and alerting machinery is host-type agnostic. What a host is — its operational vocabulary and its health signals — is contributed by a per-substrate provider, so a new kind of machine plugs in without the core learning about it.

Stays universalContributed per substrate
identity Every host is a stable UUID; the agent authenticates with a key that is only ever stored hashed. The hostname is informational.
metrics CPU, memory, disk, uptime are common to every OS, so threshold alerts work on any host on day one. A substrate adds its own typed snapshot on top.
vocabulary Docker speaks containers and images; Windows speaks services and scheduled tasks. Each provider declares its own; the hub validates against the right one per host.
events A crash is a crash; the universal alert kinds fire everywhere, while a substrate contributes its specific ones (a stopped service, a subsystem ending).

§ 07 / BoundariesWhat Watchtower is not

Deliberately out of scope
  • Not an actuator. It does not change hosts. Every action lives behind the authorization gate, in a different part of the platform. This is the invariant, not an accident of the current build.
  • Not a click-through dashboard. There are live views, but the intended interface is a conversation. If you want panels to hunt through, this is the wrong tool.
  • Not an agent that decides. The hub's reflexes are fixed stimulus-and-response, not judgement. Decisions that need reasoning are made elsewhere and remain accountable there.
  • Not an inbound service on your hosts. Agents dial out. Nothing on a managed machine listens for the hub.

Managing more hosts than a dashboard can keep up with?

Watchtower is aimed at small fleets that have outgrown clicking through panels but don't want a heavyweight observability stack. The best way to see whether it fits is to describe what you're running.