Opening proof path
SIRJ is loading the workspace, connector, or public page with the same proof path intact: ad spend, lead, booked job, invoice, paid.
See how SIRJ exposes connector health, missing setup, sync cadence, stale data, recent sync runs, reauthorization needs, and provider failures before reports use the data.
Buyer answers
Connector health explains what SIRJ does when a source is connected but not ready, stale, failing, disconnected, or waiting on reauthorization.
Connector health summarizes each connection's provider, connection status, computed health state, missing setup checks, sync mode, cadence, last successful sync, last failed sync, next sync time, latest run, and consecutive failure count.
A buyer can see whether a source is ready for reporting, waiting on setup, stale, disconnected, failing, or needs reauthorization before trusting the dashboard.
Follow the health pathThe runtime compares connector definitions, connection status, required setup checks, credential presence, selected resources, sync state, and current time before marking a connection healthy, setup required, stale, disconnected, error, or reconnect required.
The product does not treat a connected provider as useful data until its setup and sync state can support the reporting surface.
Follow the health pathSync run records preserve status, reason, raw payload count, normalized event count, inserted and updated event counts, duration, completion time, error message, and consecutive failure count without exposing credentials.
Operational failures become inspectable rows instead of vague reporting drift, which helps teams fix source problems before a client review.
Follow the health pathDashboards, Ask Data, weekly insights, and exports inherit trust from the connected sources underneath them. If a source is stale, setup-incomplete, or failing, the product needs to show that state before a report turns partial data into a confident claim.
Source health is not an admin detail. It is the control that keeps client-ready reporting from overstating what the connected stack can prove.
Follow the health pathHealth surfaces
The public page makes the trust layer visible: health labels, missing setup, sync cadence, recent runs, severity, and escaped provider output all trace back to runtime behavior.
What users see
A reporting tool earns trust when a buyer can tell whether the source is fresh enough, configured enough, and stable enough to support the next client-facing number.
| Surface | User sees | Source path |
|---|---|---|
| Integration health table | Provider name, readable health label, missing setup checks, cadence, last success, last failure, next sync, latest run, and failure count. | Health rows are built from tenant-scoped connections, connector definitions, sync states, sync run history, setup checks, and current time. |
| Provider setup checks | Readable setup requirements such as credential connected, ad account selected, form selected, webhook active, or pipeline stages mapped. | Missing setup checks come from connector health requirements, provider resource selection, credential references, webhook setup, and pipeline mapping. |
| Recent sync runs | Succeeded, failed, or skipped sync runs with reason, raw and normalized payload counts, duration, completed time, and any escaped provider error. | Sync run records are scoped to the same account, client, and connection, then sorted newest first with consecutive failures counted from recent failed runs. |
| Severity state | Ok, warning, or critical severity based on stale data, missing setup, provider error, disconnected state, reconnect needs, or repeated failures. | Severity is derived from computed connection health and recent run history so repeated provider failures can escalate even when the row still has sync history. |
| Connector health export view | A standalone integration health table with escaped provider names, readable setup labels, cadence, last run state, and failure counts. | Integration health HTML renders overview rows through display formatters and escapes provider error text before it reaches the page. |
Health workflow
The health workflow is deliberately plain: scope the connection, evaluate setup, compare sync state with cadence, summarize recent runs, and escalate the severity that should guide reporting.
| Step | What happens | User-visible proof |
|---|---|---|
| Collect scoped connections | Connector health starts with connections that belong to the active account and client, then rejects any row that does not share the same tenant scope. | The user sees source status for the selected client workspace instead of an account-wide connector list that could blend clients. |
| Evaluate setup requirements | Each connector contributes required checks such as credential presence, selected ad account, selected form, active webhook, or mapped pipeline stages before sync output can count as ready. | The health table names the missing setup requirement in readable language so the next fix is clear. |
| Compare sync state with cadence | The runtime reads sync frequency, last successful sync, last failed sync, next scheduled sync, and current time to determine whether a source is fresh, stale, failing, or unscheduled. | Users see cadence and sync timestamps close to the health label instead of discovering stale data after a report is exported. |
| Summarize recent sync runs | Run history records manual, scheduled, webhook, resource listing, and setup-required attempts with status, reason, payload counts, normalized events, duration, and errors. | A failed source has an operational trail: what ran, why it ran, what changed, and which provider error needs attention. |
| Escalate reporting severity | Health severity moves from ok to warning or critical when a connection is stale, setup-required, disconnected, needs reauthorization, has an error state, or repeats failures. | The workspace can signal which source issue should be fixed before the next client report or Ask Data answer relies on it. |
Proof standards
These controls keep connector health from becoming decorative: the row must belong to the right workspace, name the setup gap, show the failure pattern, and render provider output safely.
Health overview construction asserts account and client scope for every connection before calculating health rows.
Missing setup checks are evaluated before stale sync state so the row names the fixable setup requirement first.
Sync history counts recent failures, keeps the latest run visible, and escalates severity after repeated failed attempts.
Integration health HTML and app shell rendering escape provider errors, setup labels, run identifiers, and connection display text.
FAQ
These answers are written for search and answer engines, but the sales job is practical: show how SIRJ spots stale or incomplete data before the client sees it.
Yes. A provider can be connected while still missing setup such as credentials, selected account, selected form, webhook activation, or pipeline mapping. The health row should show that setup state before reporting uses the source.
A connector becomes stale when its sync state falls outside the cadence expected for that provider, or when the latest successful sync no longer supports current reporting confidence.
Recent sync runs preserve status, reason, payload counts, normalized event counts, duration, completed time, error message, and consecutive failure count so operators can see what broke.
It should. Reports and Ask Data answers are only trustworthy when source freshness and setup state are visible close to the metrics those sources support.
Ready when the numbers need to hold up
Browse the integration library to see what each provider can bring into SIRJ, then open the demo to inspect health, setup, and dashboard readiness together.