Debug Airbyte syncs and read connected records from a Sazabi thread

Last verified on Nov 8, 2026.

A failed data sync is a production incident for whoever depends on the warehouse table it feeds, and the evidence is split. The job logs are in Airbyte, the downstream symptom is in your application, and the real cause might sit in the third-party API on the other end.

The Airbyte MCP connector lets the Sazabi agent, part of Sazabi's AI-native observability and security platform, read the Airbyte side while it works through the rest of an investigation. You ask in a thread, and it can check job status and logs without you opening a second tool.

What the Sazabi agent can do with Airbyte

Airbyte hosts the MCP server, and the connection signs in over OAuth. Airbyte says the server then acts as you, so the agent only reaches workspaces, connectors and connections your Airbyte role allows. From Airbyte's tool reference, the useful groups for an investigation are:

• Connections and syncs: list_cloud_connections and describe_cloud_connection show streams, schedule and status. list_cloud_sync_jobs, get_cloud_sync_status and get_cloud_sync_logs give recent jobs and their logs. run_cloud_sync and cancel_cloud_sync change state.
• Sources and destinations: describe_cloud_connector returns configuration and connections, and check_cloud_connector tests a connector's credentials.
• Direct reads: get_agent_skill_docs returns a connector's entities and parameters, execute_external_api_query runs list and get against a source API, and execute_external_sql_query runs a read-only query on a Snowflake or BigQuery destination, with only SELECT and SHOW TABLES allowed.

Direct reads are read-only, Airbyte Cloud only, and need an organization admin to enable agent access for the connector. They also count against the source's API rate limits, and queries on a destination can use its compute, so tell the agent to keep them narrow. The tools that edit connections and syncs follow Sazabi's per-connection read-only toggle.

Questions it answers

• Which connections failed in the last day, and on which stream?
• What does the error in the latest sync log say, and has it happened on earlier runs?
• Is the connector's configuration or credential check passing?
• Did the destination table receive rows after the last successful sync?
• What does this CRM or billing record look like in the source right now?

A worked example: a stale orders table after a failed sync

An alert fires because the nightly revenue report shows no orders after Tuesday. The table is loaded by an Airbyte connection from Postgres to BigQuery. You ask:

The orders table in BigQuery has no rows after Tuesday 23:00 UTC. In Airbyte,
find the connection that loads it, list its last five sync jobs, and read the
logs of the first failed one. Then check the newest created_at in the
destination.

The agent calls list_cloud_connections to find the connection, then list_cloud_sync_jobs for the recent jobs. For the first failure it calls get_cloud_sync_logs, which Airbyte describes as the way to troubleshoot failures, and reports the error. It can follow with check_cloud_connector on the source to see whether credentials still work. If direct reads are enabled for the destination, get_agent_skill_docs and execute_external_sql_query return the latest created_at with a SELECT.

The result tells you whether the problem is the pipeline or the source. A credential error in the log points at the source database. A passing check with an empty destination points back at the sync itself. Asking the agent to run run_cloud_sync is a write, so it only works on a connection that is not read-only.

How it fits with other integrations

Airbyte often sits upstream of a warehouse, so pair it with Postgres or Google Cloud when the question moves to the source or destination itself. Orchestrators such as Dagster and Temporal, both in the durable execution category, often schedule work around pipelines like this. See the integrations index for every method.