Reference · built on requestOperator by FibricIT & reliability

Integration Health

Watches sync jobs and API errors on both sides of an integration and proposes a rerun, a credential check, or a pause.

Request accessPricing ↗

About

An integration fails quietly. The sync job reports failure on one side, the API returns 401 or 429 on the other, and the dashboard that depends on both goes stale. Integration Health reads the run history that Fivetran and Workato keep, the delivery receipts and rejected payloads that Webhook Ingest records, and the error responses each connector logs.

When a connection breaks it works out which side failed and what the fix is. An expired token gets a proposed credential check and setup test. A source rate limit gets a proposed pause and a later rerun. A run that failed on a transient error gets a proposed rerun of only the failed jobs. A person approves each proposal, and the receipt records the run ids, the error, and the outcome.

This is a reference listing. It documents what Fibric would read from Integration Health and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Fivetran connections with status.setup_state of incomplete, connected, or broken, status.sync_state, status.update_state, succeeded_at, and failed_at
  • Fivetran webhook events sync_start, sync_end, connection_failure, and resync_connector, carrying data.status SUCCESSFUL or FAILED
  • Workato jobs per recipe through GET /api/recipes/:recipe_id/jobs, with status succeeded, failed, or pending
  • Delivery receipts, signature failures, and rejected payloads from Webhook Ingest, matched to the sender that produced them
  • HTTP error responses and their codes from the connectors on either side, kept as a series per integration
  • Open PagerDuty incidents on the service that owns the integration, so a break already being handled is not paged twice

Proposed actions

  • Target capability: propose an incremental sync with POST /v1/connections/{connectionId}/sync, or a historical re-sync, for a Fivetran connection whose last run failed
  • Target capability: propose running Fivetran setup tests with POST /v1/connections/{connectionId}/test after a source credential has been replaced
  • Target capability: propose repeating only the failed Workato jobs through POST /api/recipes/:recipe_id/repeat_jobs, by master job id
  • Target capability: propose pausing a connection with PATCH /v1/connections/{connectionId} while a source is rate limiting or down, with a resume time
  • Target capability: propose a trigger event to PagerDuty through Events API v2 with a dedup_key per integration, so one break makes one incident

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Rerun a warehouse sync that failed overnight

    A Fivetran connection reports sync_state paused and a failed_at from the night before. The operator proposes an incremental sync, or a re-sync if setup_state is broken, and posts the proposal to Slack for the data owner.

    With Fivetran, Slack

  • Catch a rotated key before the dashboard goes stale

    Webhook Ingest starts rejecting a sender's signatures the day a secret is rotated. The operator proposes a credential check on that sender and a PagerDuty trigger with a dedup_key if the rejections continue past the window you set.

    With Webhook Ingest, PagerDuty

  • Repeat only the jobs that failed

    When a Workato recipe shows a run of failed jobs after a downstream timeout, the operator proposes repeat_jobs for those master job ids, 25 per request, and files a Jira issue carrying the error text.

    With Jira

Requirements

  • A Fivetran API key and secret, or a Workato API client token, able to read jobs and sync, test, or repeat where you allow it
  • Webhook Ingest registered as the receiver for at least one side of the integration, with a shared secret per sender
  • A definition of each integration: the source, the destination, and the connection or recipe ids that belong to it
  • A PagerDuty Events API v2 integration key on the owning service, if you want breaks to page
Authentication
Uses the API keys and tokens of the integration, webhook, and paging connectors you attach, each with the scope you grant. It stores none itself.

Limits

  • Fivetran setup tests are limited to 250 requests a minute and source interaction requests to 500 a minute, so checks across many connections are paced.
  • Workato repeat and cancel calls take 25 jobs per request, one request a second. A job can be repeated 100 times, within its retention period.
  • It cannot read a source system's own status page. A failure it sees is the failure the sync platform or the receiver recorded.
  • It never edits a connection's credentials. A credential check is a proposed setup test after you have replaced the secret yourself.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Integration Health ↗

Questions and answers

What does a person approve?
One proposal per break: a rerun, a re-sync, a setup test, a pause with a resume time, or a page. The proposal shows the connection or recipe, the last successful run, the error text, and the side that failed. Nothing is rerun before approval.
What record is left after a rerun?
A receipt with the connection or recipe id, the run ids before and after, the error that triggered the proposal, who approved, and the result the sync platform reported. Declined proposals stay on file, so a repeat break shows its history.
Does it fix credentials on its own?
No. It cannot see or write a secret. When a 401 or a signature failure points to a credential, it proposes that you replace the secret, then proposes the setup test that confirms the replacement worked.
Ask about Integration Health

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy