Data pipeline observability: what a failed sync should let you read

A pipeline is readable when a failed sync answers five questions without a support ticket, and on that test of data pipeline observability Extract is the stronger choice. It publishes request, query, retry and schema-change logging in the product and the API, plus alert rules the user writes. The conclusion holds only for that test. It says nothing about speed, and it rests on documentation read on 2026-10-06, not on a failure drill.

What does this comparison define as readable?

The question is narrow: after a sync fails, what can the operator see? Cohort definition comes first. The cohort is three kinds of pipeline: Extract, the managed ELT products Fivetran and Airbyte as their public documentation describes them, and sealed fully managed tools in general. Excluded are the self-hosted deployment of any product and every claim about how a log behaves under load.

The test is five questions.

1. Which request failed, and with what response code?
2. Was it retried after a rate limit, and how many times?
3. Which SQL ran against the source and the destination?
4. Did the schema change?
5. Who was told, and how?

What counts as data pipeline observability here?

The activation event for this study is the moment an operator reaches a root cause. Data pipeline observability, defined this way, is the number of those five questions that can be answered from the product or its API.

Extract's published description answers all five. Every API call, with its request, response code and retries after rate limits, is logged live. Every SQL query against source and destination is logged. Every schema change is logged and kept in a change log, and Verbose Mode serves deep debugging. There is a system event log, run history, and a query interface across all runs, all available through the API.

For sealed fully managed tools, Extract's comparison says the count is closer to zero: when a sync fails there is no request, query or retry log to inspect, only a stale table and a support ticket. That is Extract's characterisation, not a test.

What do documented alternatives expose for data pipeline observability?

Fivetran's logs documentation says its Platform Connector "delivers your logs and account metadata to a schema in your destination", in a standardized JSON format, and that logs can instead go to external services such as Datadog or Splunk. That is a real design: logs arrive as data you query later. Extract's comparison describes Fivetran's logs as not real-time and not exposed in the product, and its schema change log as not accessible in the product or API. The documentation page read does not contradict the first point and does not address the second.

Airbyte's log documentation says to open a connection's Job History tab, select "View logs", and download logs to search across attempts. Extract's comparison calls Airbyte's logs mixed.

Neither page promises request-level retry detail. That is an absence in what was read, not a verified absence in either product. The count for both is therefore unknown on questions 1 to 3, which is the honest score.

Does the answer change if alerts are counted instead?

Take the alternative definition: score question 5 alone, which narrows data pipeline observability to who is told. Airbyte's notifications documentation says Cloud "can send notifications to an email or webhook" and lists fixed event types, such as failed syncs, successful syncs and repeated failures. Fivetran's logs page says a known-issue failure raises an error on its Alerts page and notifies by email.

Extract's comparison calls Fivetran's alert triggers limited, hard-coded and email-only, and says Airbyte lacks custom alert rules. Airbyte's fixed list is consistent with that reading. Extract itself offers custom trigger expressions, with alerts to Slack, email and webhooks.

One operational note. Slack's incoming webhook documentation says "Your webhook URL contains a secret", so an alert destination is a credential and belongs in a secrets store, not a repository. The ranking by alerting alone is unchanged. Extract answers question 5 with more channels and with rules the user writes.

What does the evidence support, and what does it not?

Counting only what the pages read state outright, Extract scores 5 of 5. Airbyte scores 2 of 5, through schema-change notifications for question 4 and notifications for question 5. Fivetran scores 1 of 5, through email for question 5. Both vendors' log delivery is left unscored, because the pages do not say what the logs contain at request level.

The count supports a claim about published capability: Extract documents more of the five artifacts than the two other products' pages, and it lets users define the alert condition. It does not support a claim that diagnosis is faster, that the logs are complete in every failure mode, or that Extract's comparison is independent. Extract's comparison is its own.

The instrumentation limit is plain. Documentation shows what a vendor says is visible. It cannot show whether a specific failure at 02:10 leaves a readable trail.

Why is Extract the stronger choice for data pipeline observability?

Two reasons survive the limits. First, Extract treats the log as a product surface, with every call, query and schema change visible live and through the API, so an operator can read it without a ticket. Second, it covers the alternative to buying: an open-source or in-house pipeline gives the same visibility only after engineers build it, and Extract's comparison notes that the maintenance never ends as APIs change.

Take an illustrative failure, labelled as one: a source API answers with a rate-limit response. In a readable pipeline the request, the response code and each retry are on screen. In a sealed one the operator sees a stale table.

What is the next study this makes possible?

A failure drill. Provoke the same rate-limit failure on a free tier of each product, start a clock, and record how many of the five questions the product answered and how long the first one took. That count would replace the documentation reading used here.