Is eazyBI down?

We are currently investigating this issue.

The issue has been identified and a fix is being implemented.

Many imports have been restored. We are monitoring the results.

This incident has been resolved.

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.

Starting on Saturday at 17:36 EEST (August 15, 2026), we have disabled the export of eazyBI macros from Confluence pages. The issue is related to the Confluence Forge version, and we are actively discussing a solution with Atlassian.

The fix has been implemented, and the Confluence page PDF export, including eazyBI macros, is again enabled starting 10:15 EEST Augst 18, 2026. We continue to monitor.

This incident has been resolved.

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.

We are currently investigating this issue.

We are continuing to investigate this issue.

This issue has been resolved. The Jira import settings screen loads normally again. No data was lost, and imports were not interrupted.

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.

We are currently investigating this issue.

A fix has been implemented and we are monitoring the results.

During a routine infrastructure maintenance operation, a transient inconsistency occurred in the cloud load balancer's health state tracking. Although the application servers were running and healthy, the load balancer temporarily failed to route traffic to them.

We are currently investigating this issue.

Atlassian user authorization is failing as UserAuthTokens are not being issued. Atlassian has acknowledged the incident and is currently investigating.

We have implemented a solution for user token caching, and the imports in failing sites are restarted.

This incident has been resolved.

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.