Observatory

Signal Packets

A named method for reading what an application will emit before the release train leaves. Not a nine-week programme. Not a vendor tour.

Refined dark interior with a sculptural chair and stone surfaces — The observatory metaphor: sit still long enough that a noisy packet becomes visible.

What we look at

Three questions before you ship.

First: whose identity does this packet claim, and would counsel recognise that claim? Second: if the device sleeps, retries, or dual-wakes, will you count the same action twice? Third: is this event a product fact or a design flourish — a hover, a tooltip, a widget unlock dressed as attendance?

Teams use Signal Packets as a gate on the pull request that adds instrumentation. We publish the questions here so you can run them without us. If you want them run with us, the Reading Seat on the fees page is the usual door.

Or take a longer programme

What we refuse

Sampling as a costume.

Turning sampling down to “see more” is not a method. Neither is adding twenty properties “for later.” Signal Packets will tell you to delete. If your release notes need a vanity event to look complete, write a better release note.

The quiet packet

An event that fires once, with a stable name, a documented subject, and no PII in the properties. Boring on purpose. Most catalogues do not have enough of these.

The loud packet

Retries, screen views, scroll depth, and anything a designer asked for after the demo. Useful in a lab. Poison in a North Star. We mark them; we do not baptise them as users.