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.
April 2026
Delay in log delivery in customer's external log due to an issue with our external logging services
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
There is an outage in the external logging API “Splunk Log,” causing delays. Splunk has also reported this incident on their status page: https://status.splunkcloud.com/
This resulted in a buildup of Splunk log messages in our internal queue, impacting log delivery across other logging services. The team has deployed a fix to prevent delays to other logging services. The Splunk issue also appears to be resolved, and we are actively monitoring the system.
identified
The issue has been identified and we are working to resolve it.
March 2026
Fivetran: Few Pipedrive connections are failing with the Null exception.
minorSource not attested
Last archived state: identified
View archived record details
identified
The issue has been identified and we are working to resolve it.
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: PostgreSQL Connections Using RDS Proxy Are Failing with the Error: The source database does not support a provided lock_timeout parameter
minorSource not attested
Last archived state: identified
View archived record details
identified
We are continuing to work on a fix for this issue.
identified
The issue has been identified and we are working to resolve it.
Fivetran: Fivetran REST API Failing with 404 Errors
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
We have deployed a fix for the issue causing 404 errors in the Fivetran REST API.
We will continue to monitor the service to ensure normal operation.
If you continue to experience any issues, please reach out to our Support Team.
identified
We have identified the root cause of the issue causing 404 errors in the Fivetran REST API and are actively working on a fix. We will continue to share updates as we make progress.
identified
We are continuing to investigate the root cause of the issue. Our Engineering team is actively working to identify the underlying problem and will share further updates as more information becomes available.
The team is also reviewing recent changes to determine if they may have contributed to the issue.
identified
The issue has been identified and we are working to resolve it.
3rd Party: Multiple Twitter and Twitter Ads connections are failing with "HTTP 503 Service Unavailable"
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
Many Twitter and Twitter Ads connections have recovered, and the rate of severe errors has dropped significantly over the past 2 hours.
We are still seeing intermittent 500 and 503 errors for a small subset of connections.
X (Twitter) has not yet marked the incident as resolved on their status page, and we will continue to monitor for full recovery.
https://docs.x.com/status
monitoring
A fix has been implemented and we are monitoring the results.
identified
We have reached out to the third-party to obtain the latest status on this issue and are currently awaiting their response.
Additionally, we have started observing "HTTP 500 – Internal Server Error" for a few connections.
At this time, there are no further updates available on their status page. We are continuing to closely monitor the situation and will share updates as soon as we receive more information.
identified
The third-party is still working on this incident, and there have been no further updates on their status page at this time.
We are continuing to closely monitor the situation and will keep you informed as soon as we receive any new information.
identified
The issue has been identified as being caused by a problem on the third-party side. They have also acknowledged and posted an update on their page (link below).
https://docs.x.com/status
We are closely monitoring the situation and will provide further updates as soon as more information becomes available.
identified
The issue has been identified and we are working to resolve it.
Multiple connectors under the BigQuery destination are failing with a "GCS_BG_STORAGE" error.
minorSource not attested
Last archived state: monitoring
View archived record details
monitoring
Connections syncing to BigQuery destinations are impacted due to an internal configuration error. The issue has now been resolved, and we are monitoring sync.
identified
The issue has been identified and we are working to resolve it.
Some Box Connections are failing with HTTP "429 Too Many Requests" 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
The issue has been identified and we are working to resolve it.
Some itunes_connect Connections Failing Due to Intermittent Apple App Store Connect Reporter Unavailability
minorSource not attested
Last archived state: identified
View archived record details
identified
We identified an issue with the itunes_connect Connections where sync is failing with the "Unknown failure" error.
3rd Party: Sync delays in GCP Australia Southeast1 region
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.
