Freshness & health

Every connection has a freshness summary derived from its runs — so you (and your customer, through the embed widget) can see at a glance whether an integration is healthy and when it last synced, without reading the run list.

What it reports

For each resource, and rolled up to the connection:

Health comes from the latest run's status: a succeeded run is healthy, a partial run degraded, a failed run failing, an in-flight run syncing, and a resource that has never run pending. The connection's health is the worst across its resources, and its lastSuccessAt is the freshest success — so one failing resource shows as failing even if the others are fine.

Overdue — the SLI, not just the timestamp

Health only reflects the last run's status. But a scheduled sync can be broken in a way status can't see: the run that should have fired never did (a stalled scheduler, a paused-then-forgotten connection). So freshness also derives overdue — a resource with an enabled schedule is overdue when it hasn't run in roughly 2× its cadence (the cadence is inferred from the cron). A resource can be healthy and overdue — its last run succeeded, but another should have happened by now. That's the signal that turns freshness from a timestamp into an SLI.

Where it shows

• Admin — a Freshness panel on the connection detail page: a health pill and "last synced — N records" per resource.
• Embed SDK — getConnection() now returns a freshness object alongside recentRuns, so your product can render a status pill or a "last synced" line directly:

const { connection, freshness } = await client.getConnection();
// freshness.health → "healthy" | "degraded" | "failing" | "syncing" | "pending"
// freshness.lastSuccessAt, freshness.ageSeconds, freshness.resources[]

Both surfaces call the same derivation (computeFreshness over sync_runs), so the admin view and the customer widget always agree. See Embed SDK.