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.
May 2026
3rd Party: Talkdesk connections are failing with "HTTP 404: Report file not found" Error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We have coordinated with Talkdesk, and mitigation measures have been implemented on their end. Their team is actively monitoring systems as they recover.
On our end, we are observing that connector syncs are recovering from prior failures and are now completing successfully.
We will continue to closely monitor the connector syncs and provide further updates as needed.
identified
Multiple report endpoints in the US region are returning HTTP 404 errors. Initial investigation indicates this may be linked to warning statuses for Talkdesk Explore™ Reporting and Talkdesk Workforce Management™ in the US region, as shown on the Talkdesk status page. We have reached out to Talkdesk support for more details on these failures.
Talkdesk status page:
https://status.talkdesk.com/
identified
The issue has been identified and we are working to resolve it.
3rd Party: Twilio connections are failing with "504 Gateway Timeout ERROR"
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
Syncs were failing with "504 Gateway Timeout Error" for the call endpoint due to degraded performance on the Twilio side, as indicated on their status page.
The syncs have been recovered automatically without any intervention from the Fivetran end, and we are monitoring the connections.
Twilio Status Page: https://status.twilio.com/incidents/rqlltbpn6m1z
identified
The issue has been identified and we are working to resolve it.
3rd Party: Amazon Selling Partner Connection syncs are failing with 500 Internal Server Error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
Connection syncs are succeeding, and we continue to monitor the connections closely.
identified
Syncs continue to fail due to the issue on ASP’s side. We are continuing to monitor the connections.
identified
Syncs are failing with 500 Internal Server Error due to degraded performance in the Amazon Selling Partner API, as indicated on their status page. This is a third-party issue on ASP's side, and we are continuing to monitor the connections.
ASP Status Page: https://sellercentral.amazon.com/sp-api-status
identified
The issue has been identified and we are working to resolve it.
3rd Party: Hubspot connection syncs are failing with "HTTP 500 Internal Server Error" and message: "Your HubSpot source is not available at this time. We'll retry the sync later."
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
Syncs are recovering, and we are monitoring the results.
identified
HubSpot has updated their status page, confirming the regional degradation due to the AWS outage. We are also observing that sync failure rates are decreasing. We are monitoring the situation closely.
https://status.hubspot.com/incidents/f0s8vh3hsftw ("HubSpot is experiencing a regional degradation causing issues with loading related to an AWS outage")
identified
Syncs are failing due to an issue on the third-party side, due to "HTTP 500 Internal Server Error" for the events endpoint.
At this time, there are no reported incidents or updates on the HubSpot status page related to this behaviour. We have reached out to HubSpot support for more details on these failures.
HubSpot status page link: https://status.hubspot.com/
identified
The issue has been identified and we are working to resolve it.
3rd Party: Klaviyo connection syncs are failing with Reconnect Error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We have deployed a fix for this issue, and a few of the connectors have recovered since then.
We will continue to monitor all affected connectors until they resume their normal sync functionality.
identified
Syncs are failing due to an issue on the third-party side with "HTTP 401 Unauthorized error" and the reconnect task: "We could not connect to Klaviyo due to an invalid API key. Please update the credentials."
We have reached out to Klaviyo support for more details on these failures. We are also exploring possible workarounds to mitigate the issue in the meantime.
identified
The issue has been identified and we are working to resolve it.
Many Connector SDK connections failed syncs with error "Failed to pull image after max retries"
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
This incident has been resolved. We have observed that instance rates are returning to normal levels and affected connectors are syncing successfully.
<b>Incident Summary</b>
Description:
We identified an issue for Connector SDK connections, which resulted in syncs failing with a "Failed to pull image after max retries" error.
Timeline:
Incident Start Time: 2026-05-04 21:51 UTC
Incident End Time: 2026-05-04 23:49 UTC
Cause:
An automated cleanup process removed a required image used for C...
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: Hybrid connections are delayed
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
A workaround has been applied. We've rolled back the image affecting Hybrid Deployment connectors, and syncs have resumed. Our team is working on a permanent fix.
identified
The issue has been identified and we are working to resolve it.
The Connector SDK Connection state not advancing
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 are continuing to work on a fix for this issue.
identified
We have identified the root cause and are working on the fix.
identified
We identified an issue where the connector SDK connection state is not advancing, resulting in the same data sync for the last few days.
3rd Party: Hubspot connection syncs are failing with error "Your HubSpot source is not responding at this time. We'll retry the sync later"
minorSource not attested
Last archived state: identified
View archived record details
identified
The issue has been identified and we are working to resolve it.
April 2026
3rd Party: Amazon Selling Partner Connection syncs are failing with 500 Internal Server Error
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
The connections are recovering and we are currently monitoring the syncs.
identified
We are currently seeing an increase in 500 Internal Server Error responses due to degraded performance in the Amazon Selling Partner API, as indicated on their status page. This is a third-party issue on ASP's side, and we are continuing to monitor the connections.
ASP Status Page: https://sellercentral.amazon.com/sp-api-status
identified
The issue has been identified and we are working to resolve it.
