Weatherdeck: A Local Status Board for Machines and Jobs
Weatherdeck is a status board for machines and the work running on them. The board shows as a TV or phone page fed by small pushers, as documented in the Weatherdeck repository. It is not a weather app. It is not a monitoring or alerting system.
The implementation is local and read-only. It uses only the Python standard library, the parts that ship with Python, plus one SQLite file, a database held in a single file, and one plain HTML/JS/CSS page. There is no build step. There is no CDN, a network for delivering code from outside servers. There is no telemetry, or background usage reporting. There is no root requirement.
It runs natively on Windows, macOS and Linux with the same command. No admin privileges are required.
Information arrives in two ways. Any tool can send one JSON document, a short structured text message, over HTTP. Sources are discovered rather than configured, so no list of machines is maintained by hand. Any tool can also leave a card as one small JSON file in a drop directory. The board only reads that directory.
Staleness is explicit. A source that stops reporting stays on screen marked silent and fogged. Stale data is not presented as fresh.
A demo mode is available with weatherdeck run --demo. Every push a host receives is stored as one line in its received log. That log is viewable with weatherdeck received --diff.
The broader context here is the cost of keeping peripheral visibility alive. Polling collectors that repeatedly ask for status, privileged agents and hosted dashboards tend to collect configuration and credentials. They also tend to fail in ways that look like data. Weatherdeck inverts those defaults. Push over HTTP with discovery removes inventory files. A drop directory with read-only rules removes write-back paths. Explicit silent state removes ambiguity between idle and dead. For practitioners who maintain fleets of test machines, builders or lab hosts, that combination lowers operational overhead without creating another alerting pipeline to tune.
In my view, the strict dependency budget is the decision to watch. Standard library only, one SQLite file and one static page means the runtime surface is Python itself plus the operating system. That simplifies vendoring, audit and offline operation. It also keeps parsing, retention and rendering in a small codebase that can be inspected, rather than spreading them across external packages and services. The trade is deliberate. Fewer abstractions mean fewer automatic behaviors, and more responsibility sits with the small pushers at the edge.
Looking at what this means for daily use, the received log matters as much as the pixels. One line per push with diff viewing gives operators a local ledger to reconcile what was sent against what is shown. That is useful when pushers are short scripts scattered across machines with different owners and lifecycles. Discovery plus an append-only view of inputs allows debugging without adding query layers or retention policies. The result is not observability in the conventional sense. It is ambient awareness for hardware and jobs, kept legible on hardware people already have in rooms and pockets.
