Staff sign-in
Sign in against the staff realm. Your account, not a typed name, is what lands on every audit row this panel writes.
You will be sent to the staff realm to authenticate, then returned here. The panel holds the resulting token for this browser session only.
Platform health
Queue depth
count(*) on ops.queue_message and ops.queue_message_dlqNo logical queue is registered on this cell.
Scheduler leader
Worker lag
derive backlog, unprocessed uploads, unpublished outboxScheduled jobs
Error rate
Range
cell-wide counters; no cohort dimension exists on this endpointRegistered users
Active devices
active dev.device_pairing rowsUploads per day
No upload was received in this range.
Processing lag and quarantine
No upload in this range was quarantined.
Pull termination reasons
pull_report[].terminated_reason distributionNo pull report was recorded in this range.
Reason for access
not recordedA staff read of one person's data is refused without a reason. Record it here before the panel will issue any query against /admin/v1/users/**; it is stored on the audit row with your staff id, the user_key read and the fields returned.
Find the account
Record a reason for access to unlock the lookup.
Account
Device pairings
This account has no device pairing.
Correct a clock anchor
A pairing marked RTC RESET SUSPECTED above means the ring clock jumped and the sync.clock_anchor row taken with that upload is no longer trustworthy. Paste the anchor_id from the upload's quarantine detail or from its audit row, then change only the fields you are sure of; the rest are left as they stand. This corrects the anchor itself. It does not rewrite the records already stored under the contaminated clock — the server returns the scope of what it did, and reprocessing the window is the second half of the fix.
Recent uploads
No upload has reached the cell for this account.
Open quarantine
Nothing is held in quarantine for this account.
Recent daily summaries
No day has been summarised for this account.
Reprocess a window
A day that reads unscorable above is usually a day whose derived rows were written before the fix. This marks the day dirty in ops.recompute_task from the stage you choose, and the derive worker recomputes it. Preview first: a dry run queues nothing and only tells you which local days and families would be marked.
Preview a plan to see which days would be marked.
This read
Filters
audit search is itself auditedChain verification
Entries
No audit row matched these filters.
Config drift
Two lists must be empty on a healthy cell. A dev.payload_schema row marked active with no adapter loaded means uploads on that schema reach a binary that never learned to read them. A loaded adapter with no schema row means the binary carries code the registry has forgotten. Either way the registry bundle and the running binary disagree.
Adapter inventory
This cell holds no dev.payload_schema row.
Reload the registry
This re-reads the registry seed into the cell and re-counts what it applied: metric families and definitions, device models, hardware revisions, device capabilities, payload schemas and consent documents. It is how the drift alarm above is cleared once the seed has been corrected. No one person's data moves, but the whole cell reads the new registry the moment it lands, so the press is confirmed.
Algorithm versions
core.current_algo_version holds one pointer per algo_key, and every derived row is stamped with the version that computed it. A family is a named bundle of algo_keys; flipping one moves every key in the bundle to the version you name. Only a version already registered active in core.algorithm_version can be flipped to, and nothing already computed is restated by the flip — reprocess the affected accounts from the lookup screen for that.
No algo_key has a current version pointer on this cell.