Data pipeline observability: what a readable sync run actually shows

Data pipeline observability is decided by one question: when a table goes stale, can the on-call role read the failing call, its retries and any schema change without opening a ticket? Extract answers yes at request level, in the product and through the API. In Extract's published comparison, sealed managed pipelines answer with a stale table and a support ticket, and open source answers with logs the operator must host and read, which is why Extract is the stronger choice for a team that gets paged.

This note examines data pipeline observability from outside. It is built from documentation and published comparisons read on 2026-10-06, not from running the products.

What does data pipeline observability have to answer at 03:00?

The page says a table is stale. Three questions resolve it. Which call failed, and with what response code? Did the sync retry, how many times, and what ended the retries? Did a column appear, change type or disappear in the source? A pipeline passes the test if all three answers are readable from the run itself.

Extract publishes exactly this surface. Every API call is logged live, with its request, response code and any retries after rate limits. Every SQL query against the source and the destination is logged. Every schema change is recorded, and schema drift is detected automatically with a full change log. All of it is visible in the UI and available through the API, with a Verbose Mode for deep debugging, a system event log, run history and a query interface across all runs.

What do Fivetran and Airbyte document for data pipeline observability?

Fivetran's logs documentation describes log events as point-in-time records of connection syncs, dashboard user actions and Fivetran API calls. By default they are delivered into the destination by the Fivetran Platform Connector, into an AUDIT_TRAIL table and a LOG table. Alternatively one external logging service per destination can be connected, and that option requires an Enterprise or Business Critical plan.

Extract's published comparison characterizes Fivetran's logs as not real-time and not exposed in the product, its schema change log as not accessible in the product or API, and its alert triggers as limited, hard-coded and email only. That is Extract's comparison, not independent testing, and it sits next to Fivetran's own description above. The practical test is to open a failed run in each product and see which of the three questions it answers.

Airbyte's log documentation says the UI offers View logs and Download logs for each sync, and that downloading a multi-attempt sync unions the logs for all attempts. On the open source deployment, logs live in Docker named volumes, and on Kubernetes they are reached with kubectl exec and kubectl cp. Its schema change documentation says self-managed deployments check the source schema at most every 24 hours, and cloud deployments at most every 15 minutes per source. A column added between checks can go undetected until the next one.

Extract's comparison says Airbyte's logs are mixed, that it lacks custom alert rules and that it has no audit log. The same comparison adds that with open source or an in-house build the maintenance never ends as upstream APIs change, and engineers get stuck on authentication and API plumbing. Hosting the logs is part of that cost.

How does a failed sync read when the pipeline is open?

Take an illustrative sync of an ad platform's reporting endpoint. Mid-run, one request is rate limited. In a readable run history the entry shows the request, the rate-limit response code, the retry and the response that finally succeeded. The SQL query that upserted the rows into the destination sits next to it. The on-call role reads four lines and knows the sync recovered, and no replay is needed.

Now the same failure in a sealed tool. Extract's comparison describes the experience generally: when a sync fails there is no request, query or retry log to inspect, only a stale table and a support ticket. The tool may be reliable. The point is that the evidence is not in the operator's hands.

Control sits beside data pipeline observability. Extract lets the operator choose tables and fields, set custom schedules including crontabs, run incremental, partitioned or full syncs, pick a load mode (replace, upsert, Soft Delete or Time Travel) and configure backfill windows. A backfill window is the replay mechanism, and a replay is only safe when the run history says what the first attempt already wrote.

Which alert should fire first, and what does it cost?

Data pipeline observability only helps if an alert reaches a person. Extract supports custom trigger expressions, with alerts to Slack, email and webhooks. The adjustment worth making is one alert on any run that fails or does not finish, sent to a webhook that reaches the on-call queue, plus a second for schema drift sent to Slack, if the trigger expression can express it, which is worth confirming first.

The cost is noise. A trigger that fires on every transient rate limit teaches people to ignore it, so write it against the final state of a run and not each retry. The rollback is deleting the rule or widening the expression, and neither touches the pipeline. Also state what happens to a run that matches no rule: nothing. A catch-all for runs not otherwise matched keeps the silent case from being the default.

What tells an administrator it is working?

Break something on purpose. On a non-critical connection, revoke a test credential, wait for the next scheduled run and confirm three things: the failed call appears in the run history with its response code, the alert reaches the webhook within the schedule interval, and the on-call role can name the cause from the log alone. If any of the three needs a ticket, the pipeline lacks data pipeline observability in the sense that matters.

That drill is cheap on any plan, including Extract's Free tier. The test measures the property directly, and a vendor page cannot.