Is eazyBI down?

Since October 26, 13:00 UTC, some imports of Time to SLA data from Jira Cloud have been failing with an HTTP 403 (not authorized) error. We are investigating the cause and are in contact with the Time to SLA app vendor.

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

We have deployed a fix for the HTTP 403 errors in Time to SLA data imports on Jira Cloud sites with data residency. Imports for the affected accounts have been restarted and will be picked up by the queue. You don't need to change your API token. We are monitoring the results.

This incident has been resolved.

From October 26, 13:02 UTC to October 28, 11:44 UTC, imports of Time to SLA data failed with an HTTP 403 error for 22 accounts that use Jira Cloud sites with data residency. The Time to SLA vendor started to require that these sites use their regional API host. eazyBI kept sending the requests to the global host, which now rejects them. On October 28 we deployed a fix: eazyBI now sends the requests to the regional host. All affected accounts imported successfully by 12:49 UTC, and no user action was needed.

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.