TL;DR
- ▸The Timebeat Agent emits approximately 167 telemetry fields per synchronisation cycle, grouped into nine measurement domains from raw clock offset through per-satellite signal quality to OSNMA authentication state.
- ▸Most of the fields are diagnostic — you never need to look at them in normal operations, but when something goes wrong the relevant field is the difference between a two-hour incident and a 20-minute incident.
- ▸A typical production deployment surfaces 10–15 key fields as Grafana panels and alerts on another 5–8. The rest stream into Elasticsearch for ad-hoc investigation and compliance evidence.
The nine measurement domains
Telemetry fields group by the measurement domain they belong to. The nine domains below cover every field the agent emits. Fields within a domain correlate naturally — a GNSS jamming alert will move multiple fields in the jamming/spoofing domain simultaneously, which is exactly what makes incident investigation efficient.
| Domain | Approx. fields | Primary use |
|---|---|---|
| 1. Clock offset & accuracy | ~12 | The load-bearing numbers — raw offset, filtered offset, absolute accuracy, EMA trend, granularity, compliance fields |
| 2. Steering & servo state | ~14 | Five-algorithm servo state — active algorithm, PID components, adjustment values, outlier filter state, interference-monitor backoff |
| 3. PTP topology & counters | ~20 | BMCA role, domain number, clock quality fields, per-message-type packet counters, unicast subscription counts, DSCP marking |
| 4. Upstream time sources | ~15 | Per-source offset / one-way delay / EMA / protocol / type — whether being actively consumed or monitored |
| 5. Hardware timestamping / PHC | ~10 | PHC offset strategies, smoothing mode, per-interface sample counts, 1-step PTP state, outlier filter state |
| 6. GNSS constellation / signal | ~18 | Per-constellation signal configuration, dynamic model, survey-in / fixed-position state, input-filter thresholds |
| 7. GNSS signal quality & security | ~32 | Per-SV C/N₀, pseudorange residuals, signal flags, OSNMA authentication, jamming and spoofing alerts, NMA status |
| 8. GNSS position & cross-validation | ~14 | ECEF survey position, NAV2 real-time position, drift alert, Trusted Time delta, reference system ID |
| 9. Hardware telemetry | ~32 | Timecard offset / power / oscillator state / SFP mode / watchdog / battery / oscillator aging compensation |
Why so many fields?
Clock synchronisation is a stacking problem. The PTP accuracy you measure at the endpoint is the cumulative effect of decisions made at the GNSS receiver, the grandmaster's oscillator, the PTP distribution path, and the receiving NIC's timestamping implementation. When accuracy degrades, the root cause can be in any of the stages — telemetry that covers all of them is how you find it quickly.
Domain 1 — Clock offset and accuracy
The fields operators look at most often. Raw offset is the unfiltered measurement between the host clock and its active reference; filtered offset is the servo-processed measurement used for actual steering. Absolute accuracy is the statistically-bounded upper estimate of the host's offset from UTC, and granularity is the smallest measurable time difference the hardware can resolve.
The two compliance-grade fields are absaccuracy and absaccuracy_ema — the current estimated absolute accuracy to UTC, and the exponential moving average of the same measurement over a configurable window. The EMA field is the one that feeds MiFID II and DORA compliance reports, because it smooths short-term measurement noise and surfaces slow aging effects cleanly.
Traceability chain state is validated per cycle and logged with a validity flag. If the traceability chain to the national UTC reference is interrupted — an upstream PTP source goes offline, a GNSS reference fails, a Trust Bridge feed times out — the traceability flag flips and subsequent attestations reflect the degraded state. Downstream compliance reports include the traceability state as part of the evidence pack.
Domain 2 — Steering and servo state
Every cycle, the servo produces a correction, and the telemetry captures the full state of the correction. Active algorithm (sigma / rho / alpha / beta / gamma) identifies which of the five algorithms the deployment is using. PID component values (P, I, D individually) are logged every cycle alongside the total adjustment value and the steering type (step, slew, small correction).
The outlier filter state captures whether the filter is active, which mode it is in (strict / moderate / relaxed), and which peer IDs have opted out of filtering. When the filter rejects a sample, the rejection is logged with the reason — letting an operator see in retrospect that during a specific window, the servo was discarding inputs from a particular peer because it looked like an outlier.
Interference monitor state catches the case where a third-party process is adjusting the clock. The agent detects the interference, logs the adjustment source, and backs off steering for a configurable period rather than fighting the other process. This is the field to look at during an incident where two sync services were accidentally left running — the interference monitor will have flagged it at the moment it started.
Extended step limits (forward and backward, independently configurable) govern how large a correction the servo is allowed to make. Step-rate policy is the operational lever for environments where step-change corrections are disruptive to applications — for example, distributed databases that are sensitive to clock step events during transaction window evaluation.
Domain 3 — PTP topology and packet counters
BMCA role tells you whether the local clock is acting as grandmaster, boundary clock, slave or passive. Grandmaster identity and description identify the upstream master the local clock is currently following — critical for debugging multi-master environments where the BMCA election is not producing the expected result.
Clock quality fields — class, accuracy, variance, timesource — are configurable on each clock and logged per cycle. These feed into downstream BMCA decisions across the timing fabric. A clock advertising a high class and low accuracy will be preferred; the telemetry lets you see what your clock is advertising and what your upstream master is advertising.
Per-message-type packet counters (sync, announce, delay_req, delay_resp, follow_up, signalling, management, irrelevant multicast) are the diagnostic for PTP protocol issues. A sudden spike in management messages indicates a device on the network is trying to reconfigure something. A drop in sync ingress rate indicates a network issue on the upstream path. A rise in irrelevant multicast indicates a cross-domain configuration issue. Each counter is per-second resolution so investigation can pinpoint the onset of the behaviour.
Active unicast subscription counts (sync, announce, delay_req) matter for unicast PTP deployments where a single grandmaster is serving a large number of clients. Sync Insight exposes the subscription table as a browsable telemetry field — the operator can see every client currently consuming time from this master.
DSCP QoS marking, multicast TTL, TX synchronisation delay and asymmetry compensation are the tuning knobs for deployments with network-specific requirements. The WRED algorithm for inbound packet rate limiting is the protection against a malformed or runaway peer flooding the agent; the rate counter surfaces when WRED activates.
Domain 4 — Upstream time source monitoring
Per-source offset, one-way delay, EMA and protocol / type are emitted for every upstream reference the agent is aware of — whether the agent is actively syncing from it or passively monitoring it. This is the domain that tells you what your alternative time sources would have given you if the primary had failed; in monitor-only deployments (sync-insight-alongside-incumbent parallel runs), this is the domain that produces the evidence for the incumbent platform's performance.
Peer identity is captured as Clock ID plus data and persisted across agent restarts. Primary and secondary clock source hierarchy is tracked — primary sources are active by default, and secondary sources auto-activate if all primaries are lost. Source group labelling lets multi-feed deployments apply logical grouping (a group of ptp-feeds-from-venue versus gnss-from-rooftop versus white-rabbit-backup-fibre), which downstream protocols like fallback reference.
This domain is also where the parallel-deployment telemetry comparison lives. During a 30- to 90-day parallel run, the agent treats both the incumbent and the Sync Insight-native references as upstream sources and logs both continuously. At the end of the run, the telemetry database has a documented performance comparison of both platforms, side by side, from the same host's perspective.
Domain 5 — Hardware timestamping and PHC
The domain that most enterprise IT teams do not need to touch, but that becomes load-bearing for HFT / exchange deployments where sub-100-nanosecond accuracy is the target. Hardware timestamping state captures whether SOF_TIMESTAMPING_RX/TX_HARDWARE is active and whether external software timestamping fallback is engaged.
Per-interface PHC offset strategies (precise, efx/sfc, extended, PPS, basic) reflect the agent's autodetected or configured method for reading the PHC offset to the system clock. Different NIC drivers support different strategies with different accuracy characteristics; a deployment where one specific interface has migrated from precise to basic strategy is typically the signature of a driver regression or a NIC firmware change that affects timestamping.
Per-interface PHC smoothing (minimum or median), modified lucky-packet filter state, non-Gaussian PHC outlier filter state, per-interface sample counts and 1-step PTP mode state are the tuning knobs for specific NIC behaviours. PPS output on startup (channel and pin assignment) captures the hardware output configuration — essential for deployments where a locally-disciplined clock drives downstream 1 PPS to other equipment.
Domain 6 — GNSS constellation and signal selection
Per-constellation, per-frequency signal configuration captures what the GNSS receiver is currently tracking: GPS L1CA / L2C / L5, Galileo E1 / E5a / E5b, BeiDou B1 / B1C / B2 / B2a, GLONASS L1 / L2, QZSS L1CA / L2C / L5, NavIC L5, SBAS L1CA — 17 signal types across 8 constellations. In deployments with multi-band configurable receivers (the u-blox LEA-F9T on the Open Time Appliance), the active signal set changes based on site geometry, environmental conditions and operator configuration.
Dynamic platform model (stationary / portable / pedestrian / automotive / sea / airborne_1g / 2g / 4g) tells the receiver's filtering what the expected motion profile is. For fixed-site grandmasters, stationary is correct and gives measurably better timing accuracy than the default. Survey-in state (configurable duration and accuracy target) captures where the receiver is in its commissioning process; fixed-position state (ECEF XYZ cm-precision) captures the position the receiver is using for its timing solution.
Input-filter thresholds (min SV count, min C/N₀, min elevation, C/N₀ high-threshold test) control how the receiver selects satellites for the solution. Raise these thresholds in RF-noisy environments to exclude marginal satellites that contribute more noise than information. Quantisation error correction state captures whether the 1 PPS output's qerr correction is active — enabled by default.
NAV2 position drift alert threshold is the trip wire for geometric spoof detection. A receiver that has been surveyed into a specific position should continue to report that position; a spoof attempt that misrepresents the receiver's location produces a NAV2 drift that trips the alert, logged with the moment of onset.
Domain 7 — GNSS signal quality and security (32 fields, the biggest domain)
The single largest telemetry domain, reflecting that GNSS is the most likely place for things to go wrong on a modern grandmaster and that evidence of what went wrong is the difference between a resolved incident and an open investigation.
Per-SV, per-signal telemetry includes carrier-to-noise density (C/N₀ dB-Hz), pseudorange residual (pr_res and pr_res_abs), quality indicator, frequency ID, signal ID and constellation. Signal flags per measurement are rich: pseudorange used / smoothed / corrected, carrier range used / corrected, Doppler used / corrected, health flag, authenticated flag. Ionospheric model corrections are logged raw and elevation-adjusted. NMEA complement data adds per-satellite azimuth, elevation and SNR.
Receiver-level signal summary aggregates across satellites: total SVs used for time, per-quality-state counts (Code+Carrier locked + time sync / Code locked + time sync / Acquired / Detected but unusable / No signal / Unknown), constellation breakdown, input filter state.
Jamming and spoofing alerts come directly from the receiver's security module: jamming_alert, spoofing_alert, any_alert as boolean flags, plus textual jamming state, jamming event counter, spoofing detection state, spoofing event counter and UTC timestamp of the last security event. These are the fields that drive real-time Slack, PagerDuty or webhook alerting.
OSNMA state is the Galileo signal authentication telemetry — NMA status, CPKS (Current Public Key Status), DSM authentication state, TESLA key authentication state, per-SV authentication results (auth_status, IODE, sequence number), SV auth success / failure counts and TIM sync status. Every satellite signal currently being tracked has an authenticated / unauthenticated state that streams out per cycle.
What to alert on
In most deployments, the five GNSS-security fields that should wire directly to PagerDuty are: jamming_alert (any true transition), spoofing_alert (any true transition), OSNMA TESLA key authentication failures, NAV2 position drift beyond threshold, and sustained C/N₀ degradation across 3+ satellites. Everything else is observability for investigation, not alerting.
Domain 8 — GNSS position and cross-validation
ECEF XYZ position from both fixed-survey and NAV2 real-time solutions lets you cross-check what the receiver surveyed into versus what it is currently reporting. Position distance metric is the computed distance between the two. NAV2 validity flag captures whether the real-time solution is currently valid.
Drift alert triggers if the NAV2 position deviates from the surveyed position beyond the configured threshold. For fixed rooftop grandmasters, a few-metres threshold surfaces any significant spoof attempt; for mobile deployments, the threshold is typically higher or the alert disabled.
Trusted Time cross-validation adds an independent check — the agent measures the delta between its actively-synchronised clock and a trusted external reference. Fields include delta_time (in ms or sub-second precision), delta_time_valid flag, trusted_time_valid flag and reference system ID. The purpose is to catch silent GNSS degradation — drift that passes jamming and spoofing checks but deviates from an independent reference, which is the signature of a subtle measurement bias rather than an active attack.
Domain 9 — Hardware telemetry (Timecard + OTC + battery)
Direct telemetry from Open TimeCard (OTC) and OCP Timecard hardware that the agent is actively disciplining the clock from: offset, one-way delay, raw RMS, protocol, card type. The hardware-native measurements are typically an order of magnitude better than the equivalent software-timestamped measurements, and the delta between the two is a useful diagnostic.
Power sensor fields come from the onboard INA sensor: bus voltage, shunt voltage, current (mA) and computed power (mW). Trending these fields catches hardware degradation — a card whose current draw is slowly climbing is often in the early stages of a regulator or capacitor issue that will eventually manifest as a clock fault.
OCXO aging compensation state, oscillator type (rb-sa5x / ocxo-rod / rb-ql / fusion-xt / optical / cs-sa45), SFP high-accuracy timing mode and watchdog state (min active sources, range threshold, arming threshold) are the hardware-layer configuration telemetry. Changes here are the operator's audit trail — a firmware update that changed a watchdog threshold will show up in this domain's event stream.
Battery telemetry (charge status, voltage, current, percentage) is emitted for appliances with integrated battery backup — the Open Time Appliance Mini PT v3 and compatible platforms. Detecting battery degradation before it becomes a holdover gap during a mains power event is the operational use case.
Picking the handful of fields your dashboard actually needs
A typical production deployment's Grafana dashboard shows 10–15 key panels. The specific panel set varies by deployment type; three sample sets below match typical deployments.
| Deployment | Primary Grafana panels |
|---|---|
| Finance venue GMC (MiFID II compliance) | absaccuracy_ema, active algorithm + adjustment, BMCA role + grandmaster identity, GNSS used SV count, OSNMA TESLA auth rate, jamming_alert / spoofing_alert timeline, NAV2 position drift, holdover state, compliance report coverage % |
| Enterprise IT (NTP appliance replacement) | absaccuracy, offset trend (EMA), upstream source health, packet counter per message type, interference-monitor backoff events, alert summary (jamming / spoofing / drift), uptime per host |
| Telecom G.8275.1 fronthaul | absaccuracy + class / accuracy / variance fields, BMCA role per interface, unicast subscription count, per-message-type ingress / egress counters, DSCP marking observed, multicast TTL observed, PHC strategy per interface, packet rate WRED state |
On alerting
A good alerting policy alerts on 5–8 fields and surfaces another 10–15 as dashboard panels for investigation. Alerting on everything produces alert fatigue; alerting on nothing defeats the point of monitoring. The OSNMA, jamming, spoofing and NAV2 drift fields are almost always worth alerting on; the steering and packet-counter fields are almost never worth alerting on — they are investigation tools, not on-call triggers.
Export paths — Elasticsearch, Grafana and beyond
All 167 fields emit as ECS-compliant structured events. Elasticsearch is the native transport — libbeat output, full ILM support, configurable rollover policy, X-Pack Stack Monitoring. HTTP / HTTPS, API key or username / password, mTLS / PKI for Timebeat Cloud. A resilient buffer holds events during Elasticsearch disconnection and flushes on reconnection.
OpenTelemetry export for deployments with OTel-centric observability stacks. Pre-built Grafana dashboards as a starting point.
Third-party integrations cover the common enterprise tooling: Datadog, Splunk, PagerDuty, Slack and webhook. Agent field tagging and custom labels let the telemetry flow into existing tag-based observability systems with minimal configuration. Windows and Linux are both supported as host platforms.
SSH CLI and HTTP status endpoint provide an out-of-band view of the agent's state, useful for deployments where the operator wants a live view without depending on the full observability pipeline. RTC (hardware real-time clock) synchronisation keeps the host's CMOS clock aligned — so a host that reboots comes back up with a reasonable initial time before the agent's upstream discipline takes effect.