Telemetry
Send your machines' access events to an OpenTelemetry endpoint you own — PostHog, Better Stack, Datadog, Honeycomb, Grafana, Axiom or your own collector. Logs and traces stay on the machine.
Your machines keep a record of who did what on them. Telemetry is where a
copy of that record is sent: to an observability account you already own, named
once for the whole workspace.
There is no destination until you name one. A machine with nowhere to send
produces nothing at all, and nothing is stored in the meantime for you to catch
up on later.
Naming one
Telemetry in the cabinet's own menu, under Updates. It is the
workspace's screen rather than yours: every member reads it, and naming or
changing the destination is an admin's.
Seven places to send: PostHog, Better Stack, Datadog, Honeycomb, Grafana, Axiom,
and OTLP for anything else that speaks OpenTelemetry over HTTP. Press one and a
sheet opens with that vendor's endpoint already in the field and its own
credential named — a project API key for PostHog, a source token for Better
Stack, an ingest key for Honeycomb. The endpoint has to be https.
Save and test saves the destination and then posts one real record to it,
with the real token, so what comes back is a delivery rather than a guess at the
address.
How your machines get it
The cabinet never reaches a machine. Each machine asks for the destination on a
signed route of its own — roughly once a minute, and sooner while it is catching
up — then sends there from that moment. A machine that connects next week is
handed it on its first check-in.
The token travels with it, to every machine, because the machines are what
sends. Whoever holds a machine holds a copy: a vendor ingest key can only write,
and a Grafana access policy token or a bearer token for your own collector
carries whatever scopes you minted it with. It never comes back to a browser —
phc_••••3f2a is the whole of what any screen shows, including to the admin who
pasted it.
The destination is named in the cabinet, not on the machine. The panel has
no telemetry screen — an old bookmark there is the settings menu. The token
does not reach the panel at all.
What leaves, and what does not
Access events, listed on that screen rather than written into it: who opened
this machine, who was refused, a session started, variables changed, a tool
server connected. Each carries who and when, and the fields it may carry are
enumerated — a project's name and never its path, which variable names changed
and never a value. No prompt, no diff, no file and no output is in one of
these. Every record is signed with the machine's own identity key, so a row can
be checked against the fingerprint your fleet screen shows.
Your logs and traces, uptime checks and agent transcripts are not
part of this. They are written on the machine and read on it.
What beafk itself holds about you is a separate question, answered on
what beafk can see.
Whether it is arriving
The screen opens on the last hour — how many events the fleet delivered, in
twelve five-minute steps — and under it one row per machine with a word for what
that machine is doing: delivering, failing, not answering, not yet given it.
Nothing is queued anywhere. A machine that cannot reach your endpoint loses that
window — those events are gone rather than waiting, which is the trade for
keeping none of them on the machine.
Remove the destination stops the fleet as each machine next checks in. The
token is forgotten rather than filed anywhere it could be read back, and the
counts that were kept against it go with it.