Revyz's Export Data feature converts your Jira work items, comments, worklogs, attachments, and links into human-readable HTML files and stores them in cloud storage you control: AWS S3 or Azure Blob. Because that copy lives outside Atlassian's infrastructure, your team can open it locally over your own network any time, including during an Atlassian-wide or site-specific outage when a live restore isn't possible. It runs automatically every Saturday, or on demand, and requires a Command Center for Jira/Confluence Advanced plan with Bring Your Own Storage (BYOS) configured.
Every Atlassian admin has lived through the same moment of dread: Jira won't load, Confluence spins endlessly, and Slack fills up with "Is it just me?" messages. This guide isn't about why that risk exists; Why Jira Cloud Backups Fail When You Need Them Most and The Resilience Gap cover that case in depth. This guide is about what to actually configure, before an outage happens, so your team isn't stuck waiting on Atlassian's timeline to get back to work.
Why a Standard Restore Doesn't Solve This
A standard backup restore, and even a cross-site Disaster Recovery connection, both assume some Atlassian Cloud infrastructure is reachable—either your primary site or a standby site. During a genuine platform-wide outage, or a local site failure without an active DR connection, that assumption breaks down and neither option can run. Export Data is built for exactly that gap: it doesn't depend on Atlassian being reachable at all, because the data it produces already lives somewhere else.
Backup vs. Disaster Recovery vs. Export Data: Which One Actually Helps During an Outage?
These three Revyz capabilities solve related but distinct problems, and it's worth being clear on which one you're actually reaching for when Atlassian goes down.
|
Capability |
What it protects against |
What it requires to use |
What you get back |
|
Backup |
Data loss — accidental deletion, bad automation, corrupted records |
Atlassian to be reachable again, so the restore can run against your live instance |
Your instance (or a scoped part of it) restored to a prior state |
|
Disaster Recovery |
A failed production site |
At least one Atlassian Cloud site — primary or standby — to be reachable |
Failover to a standby Jira or Confluence site |
|
Export Data |
Being locked out of your own data during an outage |
Nothing from Atlassian — the exported copy already lives in your own storage |
Read-only, human-readable access to your data, independent of Atlassian's status |
Backup and Disaster Recovery both get you back to a working Atlassian instance once Atlassian's infrastructure is available again. Export Data is the only one of the three that doesn't wait on that. It's not a restore mechanism, it's a way to keep working (or at least keep looking things up) while you wait for one.
Turning Downtime Into a Non-Event
Atlassian outages are, to some degree, unavoidable. No cloud platform offers a 100% uptime guarantee: Atlassian's own Cloud SLA commits to 99.9% uptime on Premium plans and 99.95% on Enterprise, which still leaves room for real incidents. What's avoidable is the operational blind spot that follows one. With Export Data configured ahead of time, a site outage stops being a crisis and becomes a minor inconvenience: your team pulls up the locally stored HTML files, finds the ticket or page they need, and keeps moving.
If your organization hasn't stress-tested what happens the next time Jira or Confluence goes down, now is the time to configure this, before an outage decides the timeline for you. Explore Revyz's Export Data documentation for the full setup reference.
Frequently Asked Questions
What should I do first when Jira or Confluence goes down?
Confirm whether it's isolated to your site or a broader Atlassian incident (see Is Jira Down? How to Check and What to Do for the full triage steps). If it's more than a brief blip, switch to your locally stored exported data so your team isn't blocked while you wait for a fix.
Does Atlassian guarantee 100% uptime?
No. Atlassian's Cloud SLA commits to 99.9% uptime for Premium plans and 99.95% for Enterprise plans, with service credits if it falls short. Standard and Free plans carry no contractual uptime guarantee at all.
Can I restore my Jira instance during an active Atlassian outage?
No. A live restore, and even a cross-site Disaster Recovery connection, depends on at least one Atlassian Cloud site being reachable. If Atlassian's infrastructure itself is down, neither option can run until service is restored, which is exactly the gap Export Data is built to cover instead.
What's the actual cost of unplanned downtime for a business?
Atlassian's own incident management research found that business disruption (reputational damage and customer churn) is the single largest driver of downtime cost, ahead of direct revenue loss and lost productivity. McKinsey's operations research separately found that unplanned disruptions can cost organizations the equivalent of 45% of a year's profit over a decade.
What's the difference between backup, disaster recovery, and data export for offline access?
See the comparison table above. In short: a backup restores your instance to a prior state once Atlassian is reachable again. A Disaster Recovery connection lets you fail over to a standby site, but still requires an Atlassian Cloud site to be live. Export Data is different. It stores human-readable HTML copies of your data in your own cloud storage, so your team can view it locally with no dependency on Atlassian being reachable at all.
Is the Export Data feature available on every Revyz plan?
No. It requires the Command Center for Jira or Confluence Advanced plan with Bring Your Own Storage (BYOS) configured on AWS S3 or Azure Blob Storage (see Demystifying BYOK and BYOS in Atlassian if you're not yet familiar with BYOS). It isn't available for Revyz-managed storage, and you'll need at least one completed backup job before running your first export.
How often does the data export run, and can I trigger one manually?
Exports run automatically every Saturday, with the first export taking longer since it converts every work item and attachment. Admins can also trigger a manual export at any time, tag it for easy identification, and track its status through Revyz Jobs.
