Provider resolved: . The notice publication date does not establish the outage start.
Impact Brand
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue affecting the Impact connector. The source did not return data within the expected wait period, causing syncs to fail with the following error: “The Impact server encountered an unknown failure that prevented it from fulfilling our request. We will sync later.”
Timeline:
The issue began on 2026-09-29 at 8:30 AM UTC and was resolved on 2026-09-29 at 12:18 PM UTC.
Cause:
Impact connections were failing on the performance_by_day endpoint because the poll job remained in QUEUED status and did not complete. We check the job status through the performance_by_day_queued endpoint, with a maximum of 30 retries while waiting for the status to change from QUEUED to SUCCESS. The job did not complete within those retries, causing the affected connections to fail.
Resolution:
Fivetran increased the polling wait time and implemented logic to skip the affected endpoint if its report job does not complete within the maximum wait time. This allows affected connectors to continue syncing.
monitoring
We have deployed a fix for this issue by increasing the poll job wait time and skipping the affected endpoint if the poll job does not complete within the maximum wait time.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
Next Expected Update: 3 hours
identified
We are still working on the fix.
Next Expected Update: 1 hour
identified
We have identified an issue affecting the "performance_by_day report". Report jobs are remaining in QUEUED status and are not progressing, causing affected connections to fail.
We are currently investigating the issue with third-party.
Next Expected Update: 1 hour
identified
We have identified an issue where Impact connections are failing with error "The impact server encountered an unknown failure that prevented it from fulfilling our request. We'll retry the sync later."
We are investigating the issue.
Next Expected Update: 1 hour
3rd Party: Some Datadog Connections Are Failing With 400 InvalidArgument Errors for llm_observability_span endpoint
Provider resolved: . The notice publication date does not establish the outage start.
Datadog
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue for the Datadog connector, which resulted in syncs failing with a 400 InvalidArgument error for the llm_observability_span endpoint.
Timeline:
This issue began on Sep 25, 2026, at 9:30:00 PM UTC and was resolved on Sep 27, 2026, at 3:13:00 AM UTC.
Cause:
Connections are currently failing for `llm_observability_spanentity` with a 400 error:`InvalidArgument: Cannot parse query: '@event_type:span AND ()'`
This appears to be related to a recent change on the source side, and our engineering team is investigating
Resolution:
Fivetran implemented a fix to skip the affected endpoint and allow syncs to proceed. We have also reached out to the source team to investigate the underlying issue and are currently waiting for their response.
monitoring
We have deployed a fix for this issue by skipping the affected endpoint.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
We've also reached out to the Datadog team to validate the issue and resolution approach.
Next Expected Update: 3 hours
identified
Connections are currently failing for `llm_observability_spanentity` with a 400 error:
`InvalidArgument: Cannot parse query: '@event_type:span AND ()'`
This appears to be related to recent change on the source side, and our engineering team is investigating
Next Expected Update: 2 hours
identified
The issue has been identified and we are working to resolve it.
Fivetran: Some MNTN Connections Are Failing With 400 INCOMPATIBLE_TABLE_COMBINATION Errors
Provider resolved: . The notice publication date does not establish the outage start.
MNTN
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue for the mountain connector, which resulted in syncs failing with a 400 INCOMPATIBLE_TABLE_COMBINATION error.
Timeline:
This issue began on September 25 at 6:30 PM UTC and was resolved on September 26 at 1:50 AM UTC.
Cause:
Connectors started to fail because `api3.mountain.com/apidata` has started rejecting requests that combine `graph.*` fields with `SegmentInfo.*` fields due to a deprecation of query parameters on the source side.
Resolution:
Fivetran implemented a skip-on-failure mechanism to bypass 400 errors and allow syncs to proceed. We have also reached out to the source team to investigate the underlying issue and are currently waiting for their response.
monitoring
We have deployed a fix for this issue by skipping the affected endpoints with a dashboard warning.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
Next Expected Update: 3 hours
identified
We're working on a change to skip the affected endpoints with a dashboard warning. This will allow other endpoints to continue syncing while the underlying issue is resolved.
We've also reached out to the MNTN team to validate the issue and resolution approach.
identified
We've identified an issue affecting approximately 37% of MNTN connections. They're failing because `api3.mountain.com/apidata` has started rejecting requests that combine `graph.*` fields with `SegmentInfo.*` fields. This appears to be because of a deprecation of functionality on the source API. Our engineers are investigating.
Fivetran: Issue Selecting Root Partitioned Tables in Connector Schema
Provider resolved: . The notice publication date does not establish the outage start.
Amazon Aurora PostgreSQLAmazon RDS for PostgreSQLAzure Database for PostgreSQLGoogle Cloud SQL for PostgreSQLHeroku PostgreSQLPostgreSQL
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We were unable to select the root partitioned tables from the schema tab and saw the following message:
Cannot select - Table not included in publication <publication_name>. If you wish to sync it, please include the root partitioned table or all of its partitions in the publication.
Timeline:
This issue began on September 25, 2026 at 05:00 UTC and was resolved on September 25, 2026 at 20:00 UTC.
Cause:
A recent code change introduced stricter handling for partitioned table syncs, which caused some tables to be deselected.
Resolution:
We reverted the change, which restored the affected tables. Because the state had already been cleared, the tables were synced again as new tables.
monitoring
We are continuing to monitor all affected connectors after the recent fix deployment.
Next Expected Update: 3 hours
monitoring
We have deployed a Hotfix for this issue.
The affected tables will be re-added automatically and resynced by Fivetran.
Next Expected Update: 2 hours
identified
We identified an issue where certain Root Partitioned tables were unintentionally unselected or could not be selected for sync.
The root cause has been identified, and we are working to resolve the issue.
3rd Party: OpenAI connections intermittently failing due to a 404 error in the video endpoint.
Provider resolved: . The notice publication date does not establish the outage start.
OpenAI
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue for OpenAI which resulted in syncs intermittently failing with a 404 error on the video endpoint.
Timeline:
This issue began on 2026-09-25 at 10:28:55 UTC and was resolved on 2026-09-25 at 14:57:55 UTC.
Cause:
Incident caused by OpenAI
Resolution:
We deployed a fix that skips the video endpoint when this error occurs and surfaces a warning in the connector dashboard instead of failing the sync. The Warning will say "We're skipping the video endpoint because it isn't available for your Cvent account. If you expect video data, contact Openai support to confirm the Video module is enabled for your account."
monitoring
We have deployed a fix to handle this error. We are currently monitoring the affected connections, which are now recovering.
identified
We are continuing to monitor the issue affecting OpenAI connectors, which are intermittently failing with a 404 error on the video endpoint. A fix has been raised and is awaiting deployment.
investigating
We have identified an issue in which OpenAI connectors are intermittently failing with a 404 error on the video endpoint. A fix has been raised and is awaiting deployment. We are continuing to monitor the syncs.
Fivetran: A few Quickstart transformations are unable to complete successfully
Provider resolved: . The notice publication date does not establish the outage start.
Transformations
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue that caused some Quickstart transformation jobs to fail.
Timeline:
The issue began on September 25 at 04:31 UTC and was resolved on September 25 at 12:06 UTC.
Cause:
The recent dbt v2 (2.0.6) package update introduced compatibility issues with some model packages, causing affected Quickstart transformation jobs to complete unsuccessfully or fail.
Resolution:
We deployed a fix to prevent Quickstart transformations from using dbt v2 (2.0.6) package images and corrected the associated database state.
monitoring
A fix has been implemented and we are monitoring the results.
identified
The issue has been identified and we are working to resolve it.
Provider resolved: . The notice publication date does not establish the outage start.
Amazon Aurora MySQLAzure Database for MySQLOracleOracle RDSGoogle Cloud SQL for MySQLMagento MySQLMagento MySQL RDSMySQLMySQL RDSHigh-Volume Agent OracleHVA SAP ECC on OracleHVA SAP ECC on Oracle with NetWeaverOracle EBSOracle RAC
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue for a few connections, which resulted in syncs stalled/long-running syncs with no error.
Timeline:
This issue slowly began for a few connections on September 21 at 9:00 AM UTC and was resolved on September 25 at 12:00 AM UTC.
Cause:
A temporary surge in activity from a group of connectors reached our current capacity limit, causing slower sync times for other workloads sharing those resources. We actively expanded our overall system capacity to resolve this and restore normal speeds.
Resolution:
We have expanded our system capacity and raised our workload limits to resolve the bottleneck. We are actively monitoring performance to ensure these new limits fully accommodate peak activity and maintain fast sync speeds.
monitoring
We have deployed a fix for this issue: Stalled/long-running syncs.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
Next Expected Update: 2:00 AM UTC
identified
We've added new resources and moved most of our system over to it. While we're finishing up the move, new and active syncs are already using the new resources, so we are seeing better sync performance now and old stalled syncs are recovering.
identified
We identified that syncs were competing for resources with other workloads running on the same infrastructure, which contributed to the slower sync times.
We are expanding underlying capacity to mitigate the issue and improve service performance.
investigating
We have identified an issue where Oracle and MySQL connectors are intermittently experiencing delays and longer sync times.
We are currently investigating this in more detail.
3rd Party: QuickBooks connections failing due to TAX_RATE and TAX_CODE with QueryValidationError
Provider resolved: . The notice publication date does not establish the outage start.
QuickBooks
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
Incident Summary
Description:
We identified an issue for QuickBooks connectors, which resulted in syncs failing with a "Failed to sync 2 endpoints: TAX_RATE: The request cannot be fulfilled due to bad syntax; TAX_CODE: The request cannot be fulfilled due to bad syntax" error.
Timeline:
This issue began on September 23, 2026 at 00:10 UTC and was resolved on September 23, 2026 at 07:25 UTC.
Cause:
QuickBooks (the source) stopped returning the Active field in its TaxRate and TaxCode API responses. Without that field, QuickBooks rejected Fivetran's query as invalid (QueryValidationError: value true is not valid for property 'Active'), causing syncs to fail for the TAX_RATE and TAX_CODE tables.
Resolution:
We deployed a hotfix that skips the TAX_RATE and TAX_CODE tables when this error occurs and surfaces a warning in the connector dashboard instead of failing the sync. The fix was rolled out to all affected QuickBooks connectors, and no further failures were observed after rollout. We have opened a support case with QuickBooks to address the underlying API issue on their end.
monitoring
We have deployed a workaround for this issue: the TAX_RATE and TAX_CODE tables are now skipped, and a warning is shown in the UI.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
Next Expected Update: 3 hours
identified
We have identified that this issue was caused by the source not returning the Active object for the TaxRate and TaxCode objects, resulting in an invalid query response. As a workaround, these tables will be skipped, and a dashboard warning will be surfaced. We have also reached out to QuickBooks support, as this issue is not currently listed on their status page: https://status.quickbooks.intuit.com/ .
identified
We have identified an issue where QuickBooks connectors are failing with a "Failed to sync 2 endpoints: TAX_RATE: The request cannot be fulfilled due to bad syntax; TAX_CODE: The request cannot be fulfilled due to bad syntax" exception. We are currently investigating in more detail.
Next Expected Update: 1 hour
identified
The issue has been identified and we are working to resolve it.
3rd Party: Few ADP connections are failing with connection timedout exception for worker, worker_time_card and event endpoints
Provider resolved: . The notice publication date does not establish the outage start.
ADP Workforce Now
resolved
We have resolved this incident.
monitoring
We have deployed a fix for this issue.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
Next Expected Update: 3 hours
identified
The fix is currently being tested internally. We are monitoring the results to confirm that it resolves the intermittent failures before rolling it out more broadly.
Next expected update: In 1 hour
identified
The issue is still ongoing, and connections continue to fail. We are working on the fix.
**Next expected update:** 1 hour
identified
We continue to investigate intermittent connection failures. Affected connections may fail and recover without a consistent pattern.
As a temporary mitigation, we are preparing a fix to skip the affected endpoint when a source connection times out, allowing the remaining tables to continue syncing.
Next Expected Update: 1 hour
identified
We have identified an issue in which a few ADP connections are failing with a "connection timed out" exception for the worker, worker_time_card, and event endpoints.
We are currently investigating in more detail.
Next Expected Update: 1 hour
3rd Party: Reddit Ads connections are failing due to an HTTP 503 backend read error
Provider resolved: . The notice publication date does not establish the outage start.
Reddit Ads
resolved
This incident has been resolved. We have observed that instance rates are returning to normal levels, and affected connectors are syncing successfully.
Incident Summary
Description:
Reddit’s Ads API was returning HTTP 503 responses on certain non-report metadata endpoints, including /me/businesses and /businesses/{id}/ad_accounts, causing syncs to fail with "jakarta.ws.rs.ServiceUnavailableException: HTTP 503 backend read error".
Timeline:
This issue began on Sept 18, 2026, at 5.30 AM UTC and was resolved on Sept 18, 2026, at 7.30 AM UTC.
Cause:
The issue was caused by a temporary outage on Reddit's side.
Reddit's Ads API returned intermittent HTTP 503 responses (containing an Error 54113 marker) on non-report metadata endpoints (/me/businesses, /businesses/{id}/ad_accounts)
Resolution:
This issue has been resolved source-side, and connectors are syncing successfully.
monitoring
Connectors are now completing syncs successfully again. We have not made any changes on our end, and recovery is occurring on the Reddit Ads side.
We will continue monitoring affected connectors until they return to normal sync functionality.
identified
We have identified that this issue was caused by Reddit’s Ads API returning HTTP 503 responses on certain non-report metadata endpoints, including /me/businesses and /businesses/{id}/ad_accounts. Our investigation indicates this was caused by an upstream Reddit issue.
identified
The issue has been identified and we are working to resolve it.
Legacy Incident Archive
66 archived records restored. These records predate source-at-observation attestation. They are shown as historical ServiceAlert records only and do not establish a provider-reported incident, resolution, duration, or current active state.
July 2026
3rd Party: Some Ramp connections failing with 529 response errors
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A fix has been implemented and we are monitoring the results.
identified
We have identified that the source API is repeatedly returning HTTP 529 responses, causing sync failures.
We are actively working with the third-party source to resolve the issue and will continue to provide updates.
<b>Next Expected Update: 1 hour</b>
identified
The issue has been identified and we are working to resolve it.
3rd Party: QuickBooks connections failing with “Failed to sync 1 endpoint” error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We have deployed a fix for this issue by switching to the new entity for data retrieval for the table CreditCardPayment
We will continue to closely monitor all affected connections until they have fully recovered and returned to normal sync operations.
<b>Next Expected Update: 1 Hour </b>
identified
We have identified that the issue occurs when querying the CreditCardPaymentTxn entity. The source API is returning the following error:
"invalid context declaration: creditcardpaymenttxn"
This appears to be happening because the source may have changed the entity name from CreditCardPaymentTxn to CreditCardPayment. Our team is working on accommodating this change.
<b>Next Expected Update:</b> 1 hour
identified
The issue has been identified and we are working to resolve it.
June 2026
Fivetran: Apple Search Ads connections are failing with error "HTTP 400 Bad Request"
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A hotfix has been deployed, and the syncs are recovering. We will continue monitoring the syncs
<b>Next Expected Update: 3 hours</b>
identified
We have identified that this issue was caused by a recent change, and we are currently working on reverting the changes via a hotfix.
<b>Next Expected Update: 2 hours</b>
identified
The issue has been identified and we are working to resolve it.
Fivetran: Multiple Hybrid Deployment Connections are failing
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We have deployed a fix for this issue.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
<b>Next Expected Update: 3 hours</b>
identified
We are continuing to work on a fix for this issue.
<b>Next Expected Update: 1 hour</b>
identified
We have identified that this issue was caused by a recent change, and we are currently working on a HotFix.
<b>Next Expected Update: 1 hour</b>
identified
We have identified an issue where Hybrid Deployment Connections are failing with a "Failed to generate data key for HD encryption context" or "Failed to receive message length" exception. We are currently investigating in more detail.
<b>Next Expected Update: 1 hour</b>
3rd Party: Multiple Customer.io connections are failing with 5xx error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We observed a shift in the issue behavior around 12:00 UTC for the Customer export api. While initial failures occurred during job creation, the connector is now failing during the report download phase.
- We have implemented a skip mechanism to mitigate these 502 errors on the affected endpoints, and are continuing to closely monitor all active syncs.
- Additionally, we reported the ongoing behavior to Customer.io, as their initial fix did not resolve the issue. We are currently awaiting th...
monitoring
We noticed that the connections were failing again with "502 Server Error". We've raised a hotfix, and the failures are gradually reducing. We're monitoring the affected connections.
<b>Next Expected Update:</b> < 3 hours >
monitoring
We are continuing to monitor all affected connectors after the recent fix deployment.
<b>Next Expected Update:3 hours </b> <3 hours = P2, 2 hours = P1>
monitoring
A hotfix has been deployed to skip the failing endpoints until the source resolves the issue. We will continue monitoring the connections while we wait for a response from the source team.
<b>Next Expected Update: 3 hours</b> <3 hours = P2, 2 hours = P1>
identified
We are preparing a fix to skip the failing endpoints until the source resolves the issue.
<b>Next Expected Update: 1 hour</b> <1 hour = P2, 30 minutes = P1>
identified
We identified that multiple REST API requests are failing with 502 Bad Gateway errors returned by the source API.
We have reached out to the source regarding this.
<b>Next Expected Update: 1 hour</b> <1 hour = P2, 30 minutes = P1>
identified
The issue has been identified and we are working to resolve it.
3rd Party: Some Impact Brand connections are failing with "HTTP 500 Internal server" error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A fix has been implemented and we are monitoring the results.
identified
We identified that this issue is caused by the source API returning 500 Internal Server Errors, impacting the following tables: performance_by_partner, performance_by_day, adv_performance_by_ad_media_date.
We have reached out to the source regarding this issue. We are also observing that affected connectors are recovering without any intervention from Fivetran.
<b>Next Expected Update: 1 hour</b>
identified
The issue has been identified and we are working to resolve it.
May 2026
Fivetran: Hybrid Deployment Agent jobs failing to start with error "Connection pool shut down"
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We are monitoring the results of the fix. Customers are advised to restart their HD agents.
identified
The hot fix should be reflected in the new HD agent images.
For existing HD agents, restarting the controller should resolve the issue. Customers are advised to restart their controller with the following commands:
cd ~/fivetran
./hdagent.sh stop
./hdagent.sh start
identified
We have identified the root cause and have deployed a hot fix.
identified
The Fivetran Hybrid Deployment Agent is experiencing an issue that may cause syncs to fail to start or connections to fail during setup tests and syncs. HD agent logs show the following error
"Return CreateJobResponse/Failure, Caused By User: false - CREATE_JOB_ERROR/Connection pool shut down {process_id=XXX}"
This issue only affects HD deployments in Docker/Podman environments.
3rd Party: Google Display & Video 360 connections are failing with "HTTP 502 Bad Gateway" error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A fix has been implemented and we are monitoring the results.
identified
The issue has been identified and we are working to resolve it.
Multiple connection syncs are failing with an "Internal: Failed to read token" error.
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A fix has been implemented and we are monitoring the results.
identified
The issue has been identified and we are working to resolve it.
Fivetran: Delay in User facing logs and External logs delivery
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A fix has been implemented and we are monitoring the results.
identified
The issue has been identified and we are working to resolve it.
