Record · installed 2026-10-01 · corrected 2026-10-02
The first observation profile on an operator host
On 2026-10-01 three Constellation components were installed from packages as services on one production-adjacent operator host. They observed, notified and recurred for about an hour, then the acquisition path began refusing and has refused since. This page is the public summary of the owner’s dated record; it names what ran and what happened, and leaves out the host.
What was installed
All three packages were built in one pinned Ubuntu 22.04 container and installed with their checksums verified. They are the same builds that ran the same day in a fresh Ubuntu 22.04 virtual machine (below). None of these packages is published standalone; NQ’s published 0.2.0 assets are Debian 12 builds of the same source.
- NQ 0.2.0 (source
dbe29d8, the v0.2.0 release source) asnq-ng_0.2.0_amd64.deb. Its daemon was deliberately not started: the runner owns acquisition and calls NQ per cycle. - Monitor’s host-posture runner 0.1.0 (source
81212a5; the public equivalent is ondev/operator-beta) asconstellation-host-posture_0.1.0_amd64.deb: one filesystem-capacity watcher, a status projection published every acquisition, and fixed time bounds on each stage. - Nightshift 0.1.0 (source
610525a) asconstellation-nightshift_0.1.0_amd64.deb, driven by a five-minute systemd timer through site-written glue that hands each tick a fresh NQ artifact. That glue is deployment configuration, not a component feature.
What happened, in UTC
- 17:42 — packages installed; the runner enrolled, published
healthyand began acquiring every 60 seconds; NQ produced a real root-filesystem capacity diagnostic. - 17:45:01 — one Slack message sent through NQ’s webhook adapter, recorded
accepted(HTTP 2xx). The owner confirmed seeing it at 20:10. This is the first live use of the adapter; it is one message, not qualified delivery. - 17:45:31 — a manual Nightshift tick closed one observation cycle against a live NQ artifact. The timer’s first automatic run fell into the same slot and was refused by the unique-slot claim, as designed.
- 17:51:40 — the timer fired unattended, exported a fresh artifact, claimed the next slot and closed a cycle. The posture it reported was
incompleteby construction: no present-evidence support family exists yet for filesystem capacity. - 18:49:29 — the last successful native observation, occurrence 50. From 18:44 the
qualifystage had begun exceeding its 15-second bound; from 19:00 the mandatory replay did; from 22:00 the 60-second acquire itself did. After a later reboot every cycle refused with an acquisition reconciliation failure caused by an NQ timeout, and the runner publishedunknown. That is its designed fail-closed response. - 2026-10-02 03:05 — the owner’s record was corrected: the health table that was true at 17:47 stopped being true an hour later.
Why it failed
NQ 0.2.0 validates the entire retained artifact and intake history every time it opens its store. On a host that acquires every minute, the work per invocation therefore grows without bound as the history grows. NQ’s processor time equalled wall time with idle cores available and a store of about 11 MB, so this is neither host load nor the reboot, and it does not heal itself. The same mechanism had ended an earlier sustained run in a virtual machine. The correction belongs in NQ, as a bounded, watermarked validation on the command-line acquire, replay and qualify paths; it does not belong in the runner’s time bounds or in scheduling.
The same day in a fresh virtual machine
Before the host installation, the same three packages were installed in a fresh Ubuntu 22.04.5 virtual machine. There NQ reported the capacity condition absent, then present at 97% after the disk was filled, then absent again; the runner’s posture went healthy, then degraded within 11 seconds of the fill, then healthy within 8 seconds of its removal; the runner survived a service restart and a reboot; one Slack message was accepted; and one Nightshift cycle closed. The virtual machine ran at a 10-second cadence for a short time and did not reach the failure above.
Generation one
The runner’s example bounds are a qualification profile. For this host the owner set a generation-one operational envelope: acquisition every 60 seconds and retention ceilings sized from measured rates. The journal bound of 2 GiB implies a rotation obligation of roughly 40 days, so a re-enrollment into generation two is due about early November 2026. That obligation is itself a natural first thing for Nightshift to watch.
Not claimed
- Reboot survival on the host; the virtual machine rebooted, the host was not rebooted as a test.
- Any burn-in. The profile observed for about an hour before failing closed.
- Any governed effect. AG and Docket are not installed on that host, and nothing there is part of the Alpha 2 showing.
- A cutover. The host’s older alerting path kept running throughout and still does.
- A general “healthy”. The projection’s word covers one capacity watcher, not the host.
- Dependable notification. One message was delivered and seen; there is no acknowledgment loop.
What this page leaves out
The host’s name, provider, addresses, instance and volume identifiers, on-host paths, the notification route and channel, digests of host configuration, and the other services the host runs. The owner’s full record lives in a private coordination repository; this page is the public summary and will be corrected if that record is.