eazyBI Outage History

Between August 25 \(~12:00 UTC\) and August 26 \(~09:00 UTC\), scheduled data imports in our EU region were delayed, in some cases by several hours. No data was lost, reports and dashboards remained fully available throughout, and all imports completed normally once processed. What happened. A small number of exceptionally large, long-running imports - combined with slow responses from some external data source APIs - gradually occupied all background import capacity on our EU import servers. As capacity filled, remaining imports slowed down as well, and a backlog of queued import jobs grew faster than it could be processed. Resolution. On the morning of August 26, we added additional import server capacity. The backlog cleared within an hour, and import processing has been running normally since. We apologize for the inconvenience the delays may have caused.

After the Confluence Forge upgrade, we received a very large number of export requests that turned out to be invalid: they were not genuine exports but Forge platform calls made during page views and other non-export contexts. To keep the application stable, on August 15 at 17:36 EEST, we stopped all macro exports; this meant eazyBI macros were temporarily not rendered in Confluence page exports. The fix was ready within hours, but we could not publish it immediately: the Forge platform still treated our app as a Connect app and would have turned a minor update into a major version change \(Atlassian acknowledged this as a platform bug\). Once the new Forge version was published successfully, it determines the export type and processes only genuine exports, rendering the macro unchanged in all other cases. On August 18 at 10:15 EEST, we re-enabled exports, and they continue to be processed successfully.

Opening the Jira source data import settings page returned a 500 error. A DWH table existence check, added as part of performance improvements, was performed during schema definition without a checked-out DWH connection. Cloud accounts opening Jira source data settings were affected while imports, reports, and dashboard viewing were not. No data loss or data corruption.

On June 26, 2026, eazyBI accounts that import data from Atlassian Cloud experienced authorization failures. Atlassian's authentication service temporarily returned the user tokens that eazyBI uses to access Jira on each user's behalf with a zero validity period, and eazyBI could no longer reuse them. Investigation of the incident began at 11:30 EEST, and the cause was identified at 16:35 EEST. As a workaround, we added a fallback that reads each token's actual expiry, so valid tokens can be reused. This reduces our exposure to similar Atlassian disruptions in the future. We deployed the change, restarted the affected imports at 18:11 EEST, and confirmed normal operation by 20:34 EEST. Restarting the imports restored the imported data. During follow-up, we found that calculated members on custom field dimensions had been removed and not automatically restored, so affected reports may show incomplete results until these members are restored from the audit log.

A change in the import structure introduced an unexpected error affecting project role dimension imports. The issue was identified quickly, and a fix has been deployed to prevent recurrence.

Changes in the structure of imported data caused unplanned DB performance issues. As a result, imports took longer than expected and larger queues accumulated. We are planning to optimize DB resources and performance.

We experienced a short outage caused by a hardware failure in Google Cloud infrastructure beyond our control. The incident has been resolved quickly, and we have implemented architectural changes.

eazyBI sites without an Atlassian subscription that use a development license extension had lost their license status, resulting in import errors across several eazyBI accounts. We have restored the license status validation for development extensions and verified successful import completion across affected sites.

The problem occurred due to a change in the REST API on the Atlassian side. Was fixed by Atlassian.

Atlassian incident impacted eazyBI app.

Service was unavailable due to a large number of unterminated SQL transactions, which exhausted available database connections. The issue was detected by monitoring systems; however, as it occurred outside working hours, response and remediation were delayed. To prevent recurrence, we are updating timeout configurations to reduce the risk of lingering transactions. Monitoring has been improved with severity-based alerting to ensure timely notification and response.

A third-party REST API problem

The incident was caused by an incomplete solution for Xray data import changes. Import via the Xray GraphQL API was added alongside backup processing, but unlike backups, the GraphQL API enforces project-level permissions — so instance admins who could access the full Xray backup were denied data for projects where they lacked explicit access.

Impact on the system from recently deployed changes.

Atlassian incident: [https://developer.status.atlassian.com/incidents/mc0d4jnrz122](https://developer.status.atlassian.com/incidents/mc0d4jnrz122)

SSL certificate expiration follow-up was dysfunctional.

Unexpected side effects of a newly deployed feature.

Jira REST API returned incorrect data. Fixed by Atlassian.

Changes in the Atlassian REST API made it impossible to detect whether the site has Assets and other apps.

An unexpected side effect of deployed changes.

Synchronization with Clickhouse DB did not work after Clickhouse upgrade.

Problem with eazyBI infrastructure that stuck the eazyBI import queue

The PDF generation engine failed after an automatic upgrade. Version control for the engine was implemented to use a stable version

A third party REST API problem