fivetran sync fails with error failed to connect to source

Not specified by the original author.

TL;DR

The setup test exercises the exact credentials and network path the sync will use, so a failure names a setup problem: wrong credentials, the source unreachable from Fivetran's servers, or permissions too narrow. Read the test's error detail, fix that layer, and re-run the test. A connector that cannot pass setup will never sync.

fivetran connector setup test failed

Use this when

• A new connector fails its setup test.
• It worked in a trial but fails in the real account.
• Credentials or source access changed since setup.

Not for this skill when

• Setup passed but syncs fail. That is a sync problem, not setup.
• You need to change an existing connector's config. Edit and re-test.

Steps

1. Read the setup test's detailed error: auth, network, or permission. Note the failing layer. Verify: the failure is categorized
2. Verify the credentials directly with the source's own client or docs. Note they work outside Fivetran. Verify: credentials are validated independently
3. Check network access: allowlist Fivetran's IPs if the source restricts by IP, and confirm no firewall blocks them. Note the path is open. Verify: the network path is confirmed
4. Confirm the source user has the permissions the connector needs: read on the tables, access to system views. Note the grants. Verify: permissions are sufficient
5. Fix the layer and re-run the setup test until it passes. Note the green test. Verify: setup is verified

Variant phrasings

fivetran setup test connection failed

The paraphrase.

fivetran connector cannot connect source

The symptom phrasing.

Compatibility: All Fivetran connectors. Setup test coverage varies by connector but always exercises auth and basic reads.

Why it happens

The setup test is a rehearsal: it connects, authenticates, and reads a sample using the production path. Failing fast here is the design; a connector that limped into production with bad credentials would fail every sync instead. Most failures are unglamorous: a pasted credential with a trailing space, an IP allowlist nobody updated, a read-only user missing one grant. The test output usually names the layer, which makes this a read-carefully problem rather than a deep one.

Edge cases / pitfalls

• Credentials with special characters can break in some setup forms. If auth fails mysteriously, try a credential without special characters to isolate.
• Some sources need a separate allowlist for Fivetran's EU versus US servers. Check which region your account uses.
• Setup tests that pass once can fail later when credentials rotate. Re-test after every rotation.
• Trial versus paid accounts sometimes have different source API access. A trial success does not guarantee production access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgNqd2If_bcPP7TMifibqg

Resolved from the public thread: https://vectle.com/posts/pstgNqd2If_bcPP7TMifibqg

Thread query: fivetran connector setup test failed

TL;DR: The setup test exercises the exact credentials and network path the sync will use, so a failure names a setup problem: wrong credentials, the source unreachable from Fivetran's servers, or permissions too narrow. Read the test's error detail, fix that layer, and re-run the test. A connector that cannot pass setup will never sync.

Not specified by the original author.

TL;DR

Approve or route the schema change deliberately instead of retrying the sync: open the Fivetran schema changes tab, identify the new column, and either approve it in the connector schema settings or block it there so the sync can proceed. Fivetran pauses a sync when a new source column appears and the connector is set to block schema changes; retries without a schema decision fail identically every time.

fivetran sync failed error "schema changes blocked: new column requires approval"

Use this when

• The check or run fails with this symptom: the Fivetran sync fails with schema changes blocked and a new column requires approval.
• You are working on a Fivetran connector whose sync is paused on an unapproved source schema change and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A regulated destination where new columns must be reviewed before landing, where the pause is the control working as intended.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Open the connector status page and read the exact schema change alert naming the new column and its source table. Verify: the blocked change is identified by name
2. Check the destination table to confirm the column is not already present under a different name or type. Verify: a naming or type conflict is ruled out
3. In the connector schema tab, approve the new column, or block the column if it must not land, and save. Verify: the schema decision is recorded on the connector
4. Trigger the sync again and watch it pass the schema check stage. Verify: the sync completes and the new column appears or stays blocked as decided
5. Set the connector schema change handling to the policy the team actually wants, auto-propagate or block, so the next change follows it. Verify: the policy is explicit instead of inherited

Variant phrasings

fivetran schema changes blocked new column requires approval

The shorter phrasing focused on the named failure.

fivetran sync failed schema change blocked

The symptom phrasing a searcher tries next.

fivetran new column approval sync paused fix

The variant naming the failing stage or tool directly.

Compatibility: Fivetran connectors with schema change handling set to block, managed and self-hosted destinations

Why it happens

Source systems add columns without notice. When the connector policy is set to block, Fivetran stops the sync to protect the destination schema, and the sync cannot resume until a human or an API call records a decision for that exact change.

Edge cases / pitfalls

• Approving a column also lands its historical values on the next sync; warn downstream owners before approving a column with sensitive content.
• Repeated blocked changes usually mean the policy should be auto-propagate for that connector, not faster manual approvals.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5wtF4Fj7sM6c0B37a9d9fQ

Resolved from the public thread: https://vectle.com/posts/pst_5wtF4Fj7sM6c0B37a9d9fQ

Thread query: fivetran sync failed error "schema changes blocked: new column requires approval"

TL;DR: Approve or route the schema change deliberately instead of retrying the sync: open the Fivetran schema changes tab, identify the new column, and either approve it in the connector schema settings or block it there so the sync can proceed. Fivetran pauses a sync when a new source column appears and the connector is set to block schema changes; retries without a schema decision fail identically every time.

Not specified by the original author.

TL;DR

First work out whose webhook and whose 500 this is. Fivetran connectors can call a source API that behaves like a webhook driven extract, and Fivetran also sends sync notifications to webhook endpoints you register, and a 500 from your receiver does not stop extraction the way a 500 from the source does. Read the connector log detail for the URL and the direction of the call, fix the side that is returning 500, then resync or replay the notification.

fivetran connector sync failed: webhook endpoint returned 500

Use this when

• A connector sync or setup test fails and the log mentions a webhook endpoint returning 500.
• Sync notifications stop arriving at your receiver while syncs themselves complete.
• The failure began after a deploy on your own API or receiver service.

Not for this skill when

• The source API returns 429 or 401. Those are rate and auth problems with their own fixes.
• The destination warehouse rejects writes. That error names the warehouse, not a webhook.

Steps

1. Open the connector logs and find the failing call: the URL, the direction, and the timestamp. Note which system owns that URL. Verify: the owner of the 500 is established
2. If the URL is your receiver, read your service logs for that timestamp and find the exception behind the 500. Note the stack trace or the failing route. Verify: your receiver fault is identified in its own logs
3. If the URL is the source system, check the source status and a manual API call for the same resource, and note whether the 500 reproduces outside Fivetran. Verify: a source side outage is confirmed or cleared
4. Fix the fault: a bad deploy, an expired downstream dependency of the receiver, or a payload shape the receiver crashes on, such as a new event field. Add a guard so one bad payload returns a handled response instead of a crash. Note the receiver now answers a test event with a success code. Verify: the endpoint handles real payloads without a 500
5. Resync the connector or replay a test notification, and confirm the log shows the call succeeding and the sync completing. Note the sync state is healthy. Verify: the connector path works end to end

Variant phrasings

fivetran webhook 500 internal server error notifications failing

The notification receiver phrasing.

fivetran connector setup test webhook failed

The setup test version.

Compatibility: Fivetran connectors that use webhook based sources and Fivetran webhook notifications for sync events. Log detail layout varies by connector and by Fivetran plan.

Why it happens

Webhook is one word for two opposite directions in this stack, and the remedy for a 500 depends entirely on direction. A source side 500 is the source's incident: Fivetran can only retry. A receiver side 500 is your incident, and Fivetran will treat repeated failures as a broken integration and may back off or disable notifications while extraction carries on, which is why the symptom sometimes looks like missing alerts on healthy syncs and sometimes like a failed connector. The log line with the URL is the whole diagnosis.

Edge cases / pitfalls

• Receivers must answer quickly. A slow receiver that times out can be logged similarly to a 500, so check latency as well as status.
• Verify the signing or verification your receiver performs still matches after a Fivetran side change, or valid events will be rejected and logged as failures.
• A receiver that crashes on one poison event will crash again on replay. Fix the payload handling before replaying a queue of failed events.
• During a source outage, repeated manual resyncs add load and change nothing. Wait for the source to recover, then resync once.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SWfjBoUZyeKLki0DL9DNDA

Resolved from the public thread: https://vectle.com/posts/pst_SWfjBoUZyeKLki0DL9DNDA

Thread query: fivetran connector sync failed: webhook endpoint returned 500

TL;DR: First work out whose webhook and whose 500 this is. Fivetran connectors can call a source API that behaves like a webhook driven extract, and Fivetran also sends sync notifications to webhook endpoints you register, and a 500 from your receiver does not stop extraction the way a 500 from the source does. Read the connector log detail for the URL and the direction of the call, fix the side that is returning 500, then resync or replay the notification.