The Timebeat Agent, Sync Insight and Timing Feed Service are separately priced, independently deployable products. Run any one on its own, or combine all three for an end-to-end attested timing platform — the only dependency is that Sync Insight needs the Agent to produce its telemetry.
Unified view · Agent fleet, Sync Insight, Timing Feed service — one pane
The three elements
You can buy any single element without the others. The Agent is a standalone synchronisation daemon. Timing Feed works with any PTP/NTP client. Sync Insight is the only element with a dependency — it needs the Agent installed on the hosts it monitors, because the Agent is what produces the telemetry.
Which element do I need?
We rarely see a customer buy all three on day one. Most start with whichever element maps to the problem that brought them to us, then layer in the others as the platform proves its value.
| If this is your situation… | Start with | Add later? |
|---|---|---|
| You have a grandmaster and need to prove it's in spec | Sync Insight | Optionally Timing Feed if your grandmaster retires |
| You're on AWS / colo without room to rack hardware | Timing Feed | Add Sync Insight once clients need monitoring |
| MiFID II / DORA audit exposure on timing infrastructure | Sync Insight | Optionally Timing Feed for managed UTC supply |
| You're building a timing fabric from scratch | Timebeat Agent + Sync Insight | Timing Feed if you can't source local GNSS |
| You run a managed timing service for downstream tenants | Agent + Timing Feed + Sync Insight | All three from day one |
| Distributed database / Kubernetes clock consistency | Timebeat Agent + Sync Insight | No Timing Feed needed if local GNSS is reliable |
How the elements relate
Time inputs flow into the Agent from your sources (GNSS, PTP upstream, or the Timing Feed Service). The Agent disciplines the host clock and emits telemetry to Sync Insight. Sync Insight surfaces that telemetry as observability and compliance output.
Time sources → Agent → Sync Insight · attestation chain rooted at UTC
Pricing model
Each element is priced independently. Running all three produces three line items on one monthly invoice. Each element has a 60-day break clause so you can right-size the platform as your needs change. Enterprise tiers include SLAs and compliance features activated automatically by the billing mechanism.
Library
Guides, white papers and blogs for teams evaluating the Sync Insight platform.
How PTP² Mesh turns a fleet of Timebeat Agents into a self-discovering, self-healing time distribution network. mDNS and DHT peer discovery, seat-based capacity, active-active operation and millisecond failover — for when you need redundancy without the rigidity of classical BMCA hierarchies.
Why a single-grandmaster deployment is a DORA Article 11 problem, what A/B/C redundancy looks like in a single rack unit, and how the Open Time Appliance Shelf turns three independent Rubidium Black+ grandmasters — with independent GNSS antennas — into the default finance-venue topology for 2026 and beyond.
A speculative question, not a product pitch: imagine if every machine could hand anyone independently verifiable proof of what its clock was doing at any moment in history. Would it matter? Who would benefit, what might it cost us, and would the world actually be better for it? An exploration of the idea of cryptographic UTC attestation.
An engineering-level tour of the 167 telemetry fields the Timebeat Agent emits per cycle to Sync Insight. Nine measurement domains, why each one matters for operations or compliance, and how to pick the handful of fields your Grafana dashboard actually needs day-to-day.
How the Timebeat Agent fuses GNSS, upstream PTP feeds, PPS inputs and oscillator discipline into a single weighted clock output — the same BIPM-style ensemble approach used to produce UTC itself, applied at the site level.
A virtual grandmaster clock is an IP endpoint that looks like a single PTP grandmaster to downstream clients but is backed by multiple physical Timebeat Agents — redundancy, capacity and failover at the topology level, with a single client-facing configuration.
One platform · three independent elements