Migrate from Freshstatus

Freshstatus was retired on March 31, 2026 and its own migration guide routed customers to Freshservice rather than to a replacement status-page product. During that window Freshworks emailed account owners an archive of their data and configuration. Search the mailbox of whoever owned the account: that file, or an export you took yourself before the cutoff, is what you are working from, since nothing is left to pull live.

If neither exists, this is a rebuild rather than a migration, and the honest place to reconstruct the component list from is your own incident history: the services you posted updates about are the components that mattered. The subscriber list is the part that cannot be reconstructed, and it is the reason this step is first.

Create the page, add your components, and then add a monitor for each one. This is the part worth doing differently rather than copying across: Freshstatus paired with Freshping for automated updates, and Freshping was shut down weeks earlier, on March 6, 2026, so a lot of former Freshstatus pages ended their life being flipped by hand. Here the checks and the page are the same product, so a component's state comes from a real reading. If Freshstatus served your page from a custom domain, add the same domain here on Growth or Scale and the TLS certificate is provisioned automatically once the CNAME points at us.

Trim the subscriber file out of the archive down to the email column (plus a components column if you want to scope subscriptions) and upload it into the status page's subscriber importer on Growth or Scale. Freshstatus exports are not Atlassian Statuspage's specific type,value,... shape, so they go through the generic path: one email address per row, optional header row.

Said plainly, because it is the honest tradeoff of moving a list without everyone re-opting in by hand: every imported address is queued unconfirmed and gets exactly one email asking them to confirm before they receive anything else. This is not a silent bulk re-subscribe. Nobody starts receiving incident mail because you attested a CSV; they start receiving it because they clicked confirm. An address that never confirms is purged automatically after 30 days. You attest, per import, that these addresses already subscribed to your previous page, and RealUptime records that attestation rather than independently verifying it.