How to export data from Atlassian Statuspage before the contract ends
Start the export as soon as a renewal date, price change or residency requirement makes a move likely, because the data you need is easiest to pull while the account is still active. Components, incident history and subscriber records can be pulled through the Statuspage REST API, subject to a limit of one request per second per token, so a large subscriber list or years of incidents will take a scripted, throttled run rather than a single query. Page design, delivery history and consent evidence need separate handling: the API gives you the content, but not the layout, the notification log or proof that each subscriber opted in. Confirm with Atlassian which of these records your plan and API version expose before you assume any of them can be retrieved.
Work through the export in a fixed order and store each dump with its timestamp and the token used. Export the component groups and components first, since incidents and maintenance refer to them, and record each component's ID, name, status and description. Next pull incident history with its updates and affected components, then scheduled maintenance, and finally subscribers, keeping the subscriber channel (email, SMS, webhook or Slack) and the opt-in date wherever the response includes them. Capture the page's branding, custom domain settings and any private or audience-specific page configuration by hand, because these are not part of a plain data pull. Keep the raw export read-only and separate from the working copy you will import into.
The export is only the first step. Before you switch DNS, rebuild the components as monitors or status entries on the new platform, recreate the page design and custom domain, and import the incident history so visitors see a continuous record. Then test subscriber delivery from a controlled list and confirm that the consent evidence you carried over matches the channels you will use. Plan the cutover with a short overlap, tell subscribers what is changing and when, and keep the Statuspage account active until the new page has run through at least one normal update cycle. Ask your implementation partner and the platform vendor to confirm each step in writing against your own environment.
What the Statuspage REST API exports and at what limits
This table lists each data type you need from Statuspage, the endpoint family that serves it, and what to confirm before you script the export. Read it as a checklist: the rate limit is the one fixed number here, while format and pagination must be verified in Atlassian's API documentation for your plan.
| Data type | What to pull | Format and limits to confirm |
|---|---|---|
| Components and component groups | Component names, descriptions, status and grouping, which become monitors or groups on the new page | Read through the Statuspage REST API. Confirm the response format and pagination in Atlassian's documentation for your plan. |
| Incident history with updates | Past incidents, their status changes and update messages, to rebuild history on the new page | Confirm how incidents and their nested updates are paged. Large histories may need multiple requests. |
| Scheduled maintenance | Upcoming and past maintenance windows, affected components and update text | Confirm whether maintenance is a separate endpoint family and how it filters by date. |
| Subscribers | Subscriber contact records and the component subscriptions attached to each | Treat as personal data. Confirm which fields the API returns for your plan and how consent records are stored. |
| Metrics and uptime data | Any system metrics or uptime figures the API exposes, to compare against your own monitoring history | Confirm whether metrics are available on your plan and what time ranges the API accepts. |
| Rate limit | One request per second per API token, so paced scripts with retries are required for large accounts | Plan the run time around this limit. Confirm whether the limit changes by plan or for enterprise accounts. |
| Authentication | Each export needs a token with read access to the page, and the token should be revoked after migration | Confirm the token scope and expiry rules in Atlassian's documentation before creating it. |
What does not move with the API export and how to handle each gap
The Statuspage API returns the data you need to rebuild components and history, but several things either are not documented as exportable or cannot transfer as data at all. Consent, design, notification history, team access and domain configuration all need a separate plan before you switch DNS. Confirm each gap with Atlassian before you assume it applies or does not apply to your account.
Subscriber consent records
Exporting subscriber email addresses does not necessarily carry over the basis on which each person subscribed, such as an opt-in form, a domain-level signup or an invitation. Without that record, you cannot show a regulator or privacy team why an address is on the new list. Ask Atlassian which subscriber fields the API returns and whether consent timestamps or sources are included. Where they are not, re-collect consent on the new page with a clear opt-in and keep the old export under restricted access until retention rules allow deletion.
Page design and custom CSS
Logos, color schemes, custom CSS and page layout are presentation settings that the data export does not reproduce in a portable form. Any branding you carefully tuned in Statuspage must be rebuilt on the new platform, and small differences in typography or spacing will be visible to customers. Capture screenshots of each page in desktop and mobile widths, export your logo and brand assets, and record the custom CSS by hand before you start the rebuild. Review the new pages against those screenshots before cutover.
History of notifications sent
The incident updates a subscriber received by email or SMS are a delivery log, not a page record, and that log is often not part of the API export. Without it, you cannot prove who was told about a past outage or when. Ask Atlassian whether delivery logs are retrievable and for how long. If they are not, archive your email and SMS provider logs for the period you need before those services expire, and keep the archive separate from the new status page.
Team members and access settings
Users, roles and page-level permissions that control who can post incidents or edit components are account configuration, not content. They are unlikely to come through an API export of pages and incidents, so the new platform starts with no operators. List every person with access, their role and whether they used single sign-on, then recreate those accounts and permissions on the new platform. Confirm the list with Atlassian's account documentation before you decommission the old seats.
Custom domain and TLS configuration
Custom domains on Statuspage depend on DNS records and certificates that Atlassian manages, and those certificates cannot be copied to another host. Your new status page needs its own certificate issued for the same hostname before DNS changes. Confirm with Atlassian how the custom domain is configured on your page, then lower DNS TTL in advance, issue and test the new certificate, and plan a short window in which both systems can answer while customers and any embedded status widgets update.
Export sequence with verification at each step
This sequence moves your Statuspage components, incident history and subscriber records to a staging store and a rebuilt target page, with a check at each stage so you switch DNS only after the copy matches the source.
Inventory every page and its components
The Statuspage admin is the source of truth, so start there. List each status page, its custom domain, its components and component groups, its open and recent incidents, and whether it is public, private or audience-specific. Assign one owner per page who signs off on the inventory. The step is complete when the owner confirms that the inventory matches what the admin console shows for each page, including the count of components per page and any pages that are retired but still resolve.
Create a dedicated read-only API token
Create a separate token for the export rather than reusing an administrator's credential, and record who owns it, when it was created and which pages it can read. Confirm in Statuspage's API documentation that the token scope covers components, incidents and subscribers for your plan. Store the token in your secrets manager, not in a script or ticket. The step is complete when a single test request returns the expected page record and the token owner is written in the migration log.
Plan the run around the rate limit
Statuspage's REST API accepts one request per second per token, so a large history of incidents and subscribers will take longer than a quick script run. Work out the number of paginated calls each resource needs, then schedule the export in a window where the status page is not being edited. Build the script to back off on rate-limit responses and log every call. The step is complete when a dry run against one page produces a call log that matches your pagination estimate.
Export to a versioned, timestamped staging store
Write each resource to a versioned store such as an object bucket or Git repository, with the export timestamp, the source page ID and the API token label in the file path or metadata. Keep the raw JSON unchanged and do all transformations in a separate step so the original copy stays intact. Restrict access to the store to the migration team. The step is complete when every resource type for every page has a file with a timestamp, and a checksum for each file is recorded.
Reconcile counts against the admin view
Compare record counts in the staging files with what the Statuspage admin console shows for each page: components, component groups, incidents by status, and subscriber totals. Subscriber contact details should be checked in aggregate and handled under your data protection policy. Investigate every mismatch before continuing, and note any records the API does not return, such as data visible only in the UI. The step is complete when the reconciliation sheet shows matching counts for every page, with each exception documented and signed off by the owner.
Rebuild components and incidents on the target
Recreate the component structure, groups and incident history on Uptime Kuma or OneUptime, mapping each Statuspage component to a monitor or a manually maintained status item. Import incidents in chronological order so timelines remain accurate. Configure each page's custom domain on the target without yet pointing public DNS to it. The step is complete when a side-by-side review shows the same component names, groups, current status and incident titles on both platforms for each page.
Test on a staging domain
Serve each rebuilt page on a staging hostname and test it from outside your network. Check that the page renders, that the component states reflect your monitors, that subscriber sign-up and notification delivery work for a test address, and that single sign-on works on any private page. Ask the owner of each page to confirm the content. The step is complete when each page has a signed test record with no open defects.
Switch DNS only after sign-off
Change the DNS records for each custom domain only after every page has passed reconciliation and staging tests. Keep the Statuspage configuration active until the new pages have been checked on the live domain and subscribers have been told about the change. Record the DNS change time and the rollback record for each domain. The step is complete when each live domain resolves to the target, the owner confirms the page content, and the Statuspage export remains archived with its checksums.
How the one request per second limit shapes the export run
The one request per second limit applies per API token, so the length of your export run is set by how many paginated calls your largest data sets need, not by how much data you hold overall. Before you start, count those calls. For each resource (components, incident history, subscribers and any metrics you plan to pull), find the number of records in the Statuspage dashboard, divide by the page size your script requests, and add a margin for retries. Multiply the total by one second and you have a floor for the run time on a single token. Ask Atlassian to confirm the current per-token rate and any page size limits for your plan, because these are the figures your schedule depends on. If you use more than one token in parallel, confirm whether the limit still applies per token in your account before you count on it.
Every call in the run must be resumable. Log the resource name, the page or cursor you last completed and the timestamp of the last record written to your staging store. A timeout, a 429 response or a dropped connection should retry the same page after a short backoff, not restart the export from the first page. Write each page to disk or object storage as it arrives, and keep the raw JSON so that you can re-run the transformation to the new status page format without calling Statuspage again. Schedule the first full run outside peak incident periods, such as a quiet working day with no open major incidents, so that an incident does not compete with your export for the same token or delay your review of the output.
Repeat the export shortly before cutover. Incidents opened and components changed after your first run will be missing from it, and subscribers added during the interim will not appear in the earlier file. Run an incremental pull for records updated since your last checkpoint, then compare record counts against the dashboard. Plan the final run for a window long enough to finish within your change window, and keep the DNS switch until the delta run completes and reconciles.
Questions teams ask before exporting from Statuspage
How much effort does exporting from Statuspage actually take?
The effort grows with the amount of data behind each status page. The main drivers are the number of pages, the components on each page, the depth of incident history and the size of the subscriber list, because each collection is read through the REST API separately. A long subscriber list usually needs the most requests to pull. Rebuilding the data on the new tool adds mapping work, since components, incidents and maintenance windows do not carry over in a single step. Pages with several custom domains, nested component groups or long incident histories add review time on the new side. When you ask for an estimate, request a breakdown by these counts and by the mapping work, and ask which steps are scripted and which are manual.
Can our own team run the Statuspage export without outside help?
Yes, a team with API access and someone comfortable scripting HTTP calls can pull the data internally. The pull itself is read-only, so the work that needs the most care is the rebuild and the cutover. Internal teams most often trip over pagination, the one request per second limit on each token and matching component records to monitors. A workable approach includes these steps:
- Confirm which permissions the API token needs and who holds it.
- Script the pulls with a delay that stays under the per-token limit.
- Store the raw responses so the export can be re-run and checked later.
- Rebuild the page on a staging domain and review it before any DNS change.
How long does the export run and what determines the length?
The pull time depends mainly on how many paged requests the export needs, because the API allows one request per second per token. Add up the pages across pages, components, incidents and subscribers, plus any retries, to see the call volume. Parallel tokens may shorten the pull only if your Atlassian plan and the API terms allow additional tokens, so confirm that with Atlassian before planning around it. In practice the rebuild, review and subscriber communication usually take longer than the pull. Ask any provider to state the assumed call volume, the review steps and the dependencies on your team's availability, and confirm each dependency in writing before work starts.
What does our side need to provide before the export starts?
Four roles should be named before any work begins, and one person can hold more than one role in a small company. The API access owner confirms that the account can read the status page data and manages the token. The token owner stores the credential securely and rotates it after the work ends. The DNS owner controls the records for the status domain and schedules the cutover. The subscriber communication owner writes the notice, decides the timing and handles replies. Without these owners, the export often stalls at the first DNS or messaging decision. Confirm each owner and their availability in the written scope.
What happens to Statuspage subscribers during the switch?
Subscribers stay attached to the old Statuspage until someone moves them, so they will not follow the new page automatically. The usual sequence is to announce the change in advance, publish the new page address, invite people to subscribe there and keep the old page live with a notice that points to the new one. Keep the old page running until the new subscriber flow is working and you have confirmed that alerts reach test addresses. Plan for a period of duplicate notices and for replies from people who did not expect the change. Check with your subscriber communication owner how long the old page should stay up and what the final notice says.
Can exported subscriber lists move to the new tool without a new opt-in?
Do not assume that a list can move without a fresh confirmation. An export gives you contact fields, but it does not prove the terms under which each person agreed to receive updates. Whether a transfer is allowed depends on those original terms, the privacy rules that apply to your users, and the jurisdictions involved, such as the GDPR for EU recipients. Ask your legal or privacy team to review the original sign-up wording and whether it covers a new operator and a new channel. Many teams send a re-confirmation request to the existing list and import only the addresses that confirm. Record who approved the approach and keep that record with the export files.
What does a DeployOpen export engagement cover and how is it priced?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and an export is part of that work when the scope includes it. Most engagements are fixed-scope, so the components, incidents, subscriber handling, rebuild steps and cutover support are agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful input is your count of pages, components, incidents and subscribers, plus the decisions your team needs to make. Ask for the quote to list each deliverable, the handover points and the work that remains with your team.
What to plan before the Statuspage renewal or termination date
The export itself is the easy part. The risk sits in the dates around it: when the contract ends, how long your data stays reachable, and when subscribers hear about the change. The cards below cover the decisions to lock in before you pull anything from the API, so the export is complete and the switch does not interrupt anyone who relies on your status page.
Confirm renewal and notice dates
Read your Statuspage order form or contract and write down the renewal date, the notice period for cancelling or changing plans, and who on your side can give that notice. Check whether the subscription renews automatically and whether any subscriber or team-member limits apply at renewal. Export work should finish comfortably before the notice deadline, not on the day it falls, because a missed notice can commit you to another billing period. Confirm these dates in writing with your Atlassian account contact rather than relying on the admin console alone.
Keep Statuspage live until cutover
Do not cancel the subscription or change DNS until the new status pages are reachable on their own domains, the components are mapped, and a test incident has been published and seen from outside your network. Keep the Statuspage pages and their CNAME records in place during this window so customers who open the old address still see accurate status. Plan a rollback path: if the new page fails, you should be able to point DNS back without rebuilding anything.
Confirm post-termination data access
Ask Atlassian, in writing, how long your page history, components, incident records and subscriber lists remain retrievable after the subscription ends, and whether the API stays available during that period. Do not assume exports will still work after termination. If the retention window is short or undocumented, run the full export while the account is active and verify the output before the final billing date. Record the name of the person who gave the answer and the date.
Plan token revocation and access removal
Create a dedicated API token for the export and record which people and automation hold any other tokens or admin logins on the page. After the export is verified, revoke the export token and remove team members who no longer need access. Check that no CI job, monitoring script or chat integration still calls the Statuspage API, because those calls will fail once the page is retired. Keep a short list of what you revoked and when, so the audit trail for the migration is complete.
Decide ownership of the export archive
The exported JSON and CSV files contain component names, incident text and subscriber contact details, so they are personal data as well as operational records. Name one owner for the archive, store it in an access-controlled location on your own infrastructure, and set a retention period that matches your records policy and any data protection obligations that apply to your subscribers. Restrict who can open the subscriber file and log each person who does. Do not email the archive or place it in a shared drive without access controls.
Time the subscriber notice
Subscribers who receive Statuspage email or SMS notifications will need to subscribe again on the new page, and you cannot move their consent for them. Decide the notice date so customers learn about the new address and the new subscription link before the old page goes dark. Publish the notice on the existing Statuspage and by direct email where you have a lawful basis to do so. Confirm the wording with your legal or privacy team, and keep the date of each notice in the migration log.
What to rebuild on Uptime Kuma or OneUptime before switching DNS
Uptime Kuma is a lightweight, self-hosted monitoring tool with status pages built in, so the rebuild starts with monitors rather than page widgets. Each Statuspage component that customers see should map to one or more monitors that check the real service, such as an HTTP(s) check against a health endpoint, a TCP check on a database port, or a push monitor for a batch job. Group related monitors so the public page reads the way the old Statuspage did.
- Map components to monitors: Build a table from the exported component list with the component name, the Statuspage status it had, and the monitor type that will replace it. Monitors can be HTTP(s), keyword, JSON query, TCP, ping, DNS, push or Docker container, so choose the type that matches what the component promises.
- Create one status page per domain: Uptime Kuma supports multiple status pages, and each can be mapped to a specific domain. Create a page for each Statuspage custom domain and confirm the DNS and TLS path for each before the cutover.
- Wire notifications: Configure the notification services your team uses, such as Slack, Discord, Telegram, Pushover or SMTP email, from the supported list of more than 90 services. Test each channel with a forced failure on a non-production monitor.
- Recreate incident history manually: Plan for past incidents to be written up as static records or archived in a document, since the rebuild should not be assumed to import Statuspage incident timelines.
- Rebuild subscriber alerting separately: Statuspage subscribers do not transfer automatically, so decide which audience gets email, which gets chat alerts and how consent is recorded.
Confirm the current release and its feature set in the project's releases page before you plan the build.
OneUptime covers status pages, incident management and on-call in one platform, so the rebuild has more parts than an Uptime Kuma move. Public and private status pages, scheduled maintenance, incident history and subscriber notifications all need to be re-created and checked against the exported Statuspage data. Plan the order so pages and monitors exist before subscribers receive any notice that points them at the new address.
- Re-create public and private pages: Build each public page with its components, branding and custom domain, then build private pages for internal audiences. Compare the layout against the Statuspage original with a test visitor before DNS moves.
- Carry over incident history and scheduled maintenance: Recreate open incidents, recent resolved incidents and planned maintenance windows that subscribers still reference. Decide with your communications owner how much history is needed on day one.
- Re-enter subscribers through notification options: Import or re-enroll subscribers only where you hold a clear record of consent for the channel used. Treat email, SMS and webhook subscribers as separate lists with separate consent evidence.
- Set single sign-on for private pages: The Community Edition includes SAML and OIDC single sign-on, so connect the private pages to your identity provider and test group-based access with a non-administrative account.
- Check Enterprise Edition needs: SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency are part of the Enterprise Edition. Confirm with OneUptime through sales whether any of these are required for your audit or residency needs, since they are priced separately.
Confirm the current version and its feature set in the project's releases page before you schedule the build.
Whichever destination you choose, the new status page should be verified against the exported data before DNS changes. Verification checks that every component appears, every incident the business still references is visible, and every notification path fires. Running the new page in parallel with Statuspage for a short period gives you a way to compare both before subscribers are redirected.
- Compare component inventories: Match the exported component names, groups and order against the new page, and record any component with no matching monitor.
- Test status transitions: Force a degraded and an outage state on a test monitor and confirm the page changes, the public banner appears and the notification reaches each channel.
- Validate domains and certificates: Confirm each custom domain resolves to the new host, presents a valid certificate and redirects correctly from the old address during the transition.
- Review access controls: Check that private pages reject unauthenticated visitors and that group membership in your identity provider maps to the right audience.
- Retain the export: Keep the raw JSON and CSV exports, with checksums, in your records so that the migration can be reviewed later.
The cutover checklist should be signed off by the owner of each service listed on the page, not only by the team building the page.
How DeployOpen scopes and delivers a Statuspage export and migration
DeployOpen plans and delivers the export of components, incident history and subscribers from Atlassian Statuspage as a fixed-scope piece of work, agreed in writing before anything is pulled. The output is a set of documented extracts and a rebuilt status page, ready for the cutover on your own infrastructure.
How we scope
- The written scope lists which Statuspage pages, components, incidents and subscriber lists are exported.
- We confirm the API token type, its access rights and how the one request per second limit affects the export window.
- The scope names the target platform, Uptime Kuma or OneUptime, and which status pages and custom domains will be rebuilt.
How we build
- We write export scripts that pull components, incident history and subscribers through the Statuspage REST API and store them in your environment.
- We map each exported component to a monitor or status page group on the target platform and record every gap.
- We test the import on a staging instance, compare record counts against the source and check that subscriber consent flags carry over.
How we hand over
- You receive the export scripts, raw extracts, mapping tables and a reconciliation report with the counts and any exceptions.
- The runbook covers the DNS cutover order, custom domain setup and the subscriber notice you send before switching.
- Deliverables are stored in your repository or document system so your team can rerun the export without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing of the new status page are available as a retainer after handover.
- Retainer scope, response expectations and fees are agreed in writing, and no prices appear in this page.
- Questions about what your own environment, account or plan allows should be confirmed with Atlassian and the target platform before the scope is signed.
