Triage Airbyte sync failures and route to Slack and Linear

When Airbyte fires an outgoing webhook for a failed sync, triage the failure end to end and route it to the right place. The trigger is Airbyte's native sync-failure webhook — the incoming payload includes the connection id, job id, error message, errorType (config_error, transient_error, or system_error), and records extracted. Do not schedule this on a cron or poll Airbyte; the webhook is what kicks it off.

Step 1 — enrich the payload. Call Airbyte's Get Job Details operation with the job id from the webhook to confirm status and pull sync metrics (records extracted, bytes, duration). Then call Airbyte's Get Connection Details operation with the connection id to resolve the human-readable connection name, source name, and destination name. If either call fails, still proceed with whatever the webhook already gave you and note the gap in the Slack message.

Step 2 — classify. Trust the errorType field from Airbyte first: config_error means a human needs to act (bad credentials, schema drift, missing permissions); transient_error is safe to ignore or let Airbyte retry (rate limits, network blips); system_error is an Airbyte-side or infrastructure issue. If the payload is missing errorType, infer it from the error message text and say in the alert that the classification was inferred.

Step 3 — post to Slack. Use Slack Send a Message to post to a designated data-engineering channel (make the channel a top-level input so it's easy to change). The message should be scannable Slack mrkdwn: a headline line with the classification and connection name, then a compact block with source → destination, records extracted, error type, and the raw error message, and finally a link to the Airbyte connection URL so someone can jump straight in. Use emoji or a leading tag to make the classification obvious at a glance.

Step 4 — escalate to Linear when it matters. Also create a Linear issue with Linear's Create Issue operation when either of these is true: the classification is config_error, or this is the second consecutive failure on the same connection (compare against the previous failure event you've seen for that connection id — if you don't have persistent state, treat every config_error as escalation-worthy and mention that limitation in the Slack alert). Put the issue in a specified Linear team (also a top-level input), title it with the connection name and short error summary, and include the full error message, source, destination, records extracted, and the Airbyte connection link in the description. Link back to the Slack message from the Linear issue when possible.

Step 5 — don't do more than this. Do not retry the sync, do not modify the connection, and do not spam multiple channels. One Slack post per failure, one Linear issue only when the escalation rule fires. If Airbyte or Slack or Linear returns an error, log it and stop — the goal is a clean handoff to a human, not a self-healing pipeline.