Migrate from Statuspage to Uptime Kuma without losing subscriber trust
If your Statuspage renewal is coming up, or your organization needs status pages on infrastructure it controls, moving to Uptime Kuma is a monitoring redesign as much as a data export. Statuspage stores components that you update by hand or through its API, and its subscribers receive notices from Atlassian's platform. Uptime Kuma works differently: it runs checks against your services itself (HTTP(s), TCP, DNS, ping, push and more), and it publishes status pages that you host, with each page mapped to a specific domain. Before you pull anything out of Statuspage, decide which of your current components will have a real probe behind them in Uptime Kuma, because a component with no monitor will show whatever status someone types in.
Plan for a platform or SRE team to own the build, with a named communications owner who controls wording, timing and the subscriber list. The technical work covers installing Uptime Kuma from the louislam/uptime-kuma:2 image, creating monitors for each component, building one status page per audience, configuring custom domains and TLS, and testing notifications. The communications work is harder to estimate: you must decide how to carry over incident history, whether existing subscribers are invited to opt in again, and which notification channels replace Statuspage email and SMS. Ask any services firm for a written scope that names these deliverables. Cost has two parts, the one-time build and the recurring hosting, upkeep and notification delivery that you run yourself.
The main risk is trust, not data. Subscribers who receive a new sender, a new domain or a blank history during an outage will assume the status page is wrong. Run both pages in parallel for a period you agree in advance, publish a dated notice on the old page that points to the new domain, and rehearse one incident end to end before you switch DNS. Confirm with your own legal and privacy team whether subscriber contact data can move without fresh consent, and confirm with the Uptime Kuma project how its notification options and status page features match what your subscribers expect in the Uptime Kuma repository.
Which Statuspage capabilities map cleanly to Uptime Kuma
This table compares the main Statuspage capabilities with what Uptime Kuma provides, marked as clean, needs rework or gap. Read it as a planning checklist: the clean rows can move with little redesign, while the rework and gap rows need a decision before you switch DNS.
| Capability | Statuspage | Uptime Kuma | Mapping |
|---|---|---|---|
| Components | Manually defined components, grouped and shown with their status on the page | Monitors of HTTP(s), TCP, keyword, JSON query, ping, DNS, push and Docker types, added to a status page | Needs rework: each component must be re-expressed as a monitor with a check that reflects the customer-facing service |
| Incident history | Hosted incident timeline with updates, impact and postings | Status page shows monitor uptime and heartbeats; a hosted incident timeline is not a confirmed equivalent | Gap: export historical incidents to a document or archive page, and confirm what the version you run supports |
| Subscriber notifications | Email, SMS, webhook and Slack subscriber lists managed in Statuspage | Notification services for operators (more than 90, including SMTP email, Slack and Discord); subscriber list management is not confirmed | Gap to confirm: verify whether public subscribers can self-enroll and receive updates in your version before promising parity |
| Custom domains | Custom domain configured per hosted page | Multiple status pages, each mappable to a specific domain | Clean: plan DNS records and TLS certificates for each domain before cutover |
| Multiple pages | Several pages per account, subject to plan limits | Multiple status pages on one installation | Clean: map each Statuspage page to one Uptime Kuma status page with the same slug and component set |
| Private or audience-specific pages | Access restricted to authenticated subscribers or audiences | No per-subscriber access model is confirmed; access must be handled at the network or identity provider layer | Needs rework: place internal pages behind your identity provider or a reverse proxy, and test access for each audience |
| Monitoring source | Components are updated by people or the API, not by probing services | Uptime Kuma probes services itself from the host where it runs | Clean with a note: the probe location changes, so check reachability from the network that customers see |
How the migration sequence runs from inventory to decommission
The sequence moves your public and private status pages from Statuspage to Uptime Kuma in controlled stages, so each page is proven on a low-risk target before subscribers and custom domains are switched. Each step ends with a named artifact you can check before moving on.
Inventory pages, components, subscribers and domains
List every Statuspage page, including private and audience-specific pages, and record for each one its components, component groups, active and past incidents, scheduled maintenance, subscriber count and any custom domain with its DNS record and certificate. Confirm with your Statuspage administrator which subscriber data you may export and under what consent basis. The output is a written inventory, one row per page, with an owner for each page and each domain.
Export components and incident history via API
Pull components, incident history and maintenance records through the Statuspage REST API, staying within its published limit of one request per second per token. Schedule the pulls so a large history finishes without retries, and store raw JSON alongside a converted copy. The check is that record counts in the export match the counts shown in the Statuspage admin console for each page.
Map components to Uptime Kuma monitors
Build a component-to-monitor map that names the Uptime Kuma monitor type for each component, such as HTTP(s), keyword, TCP, DNS or push, and the notification channel it uses. Where Statuspage components were updated by hand, decide who will own each monitor and how manual status overrides will be handled in Uptime Kuma. The output is a reviewed map signed off by the service owners of each component.
Pilot on one non-critical status page
Build one low-risk status page in Uptime Kuma, using a single domain mapped to that page, and run it with a small group of internal testers. Check that monitors, component states, incident posts and the public URL behave as expected, and test the certificate on the test hostname. The pilot closes when testers confirm the page reflects the monitored state accurately and the certificate chain validates in a browser.
Run Uptime Kuma in parallel with Statuspage
Publish the remaining pages in Uptime Kuma while Statuspage stays live and remains the page subscribers receive updates from. Post the same incidents to both during this period and compare component states at regular checkpoints. Confirm that notification channels deliver to test recipients, and record any mismatch in a shared log. The run is complete when two consecutive reviews show no unexplained differences for each page.
Cut over custom domains by DNS change
Lower the TTL on each custom domain record ahead of the change, then point the DNS record at the Uptime Kuma host and confirm the certificate is valid for that name. Send the subscriber notice agreed under your consent review before the switch, and keep the Statuspage record available for rollback. The step is done when each domain resolves to Uptime Kuma, serves a valid certificate and shows the correct incident history.
Decommission Statuspage after rollback window
After the agreed rollback period passes without a reversion, archive a final export of each page, confirm that all subscriber consent records are retained under your policy, and disable the Statuspage pages and API tokens. Remove leftover DNS entries and update runbooks and on-call documents to name Uptime Kuma as the status source. The output is a signed decommission record listing each page, its archive location and the date its tokens were revoked.
Pulling components and incident history through the Statuspage API
Statuspage's REST API is the export path for the data you need to rebuild a status page in Uptime Kuma: components, incident history and subscribers. Each token is limited to one request per second, so plan the calls before you run them. The cards below cover what to pull, how to pace it, and what to rebuild on the new side.
Exporting components and groups
Components are the unit you will map to monitors, so pull them first and keep their IDs, display names, current status and group membership. Groups are the sections visitors see on the page, and Statuspage returns them separately from the components inside them. Confirm in your own account whether the component listing includes group IDs, display order and any hidden or private components, because those fields decide how you rebuild the layout in Uptime Kuma. Save the raw JSON before transforming anything.
Paging within the rate limit
Statuspage documents a limit of one request per second per token, so a script that loops over paged results without delay will be throttled partway through. Build a queue that waits at least one second between calls, reads the paging information from each response, and retries after a rate-limit response with a longer wait. Record the last page fetched so an interrupted run resumes instead of starting over. Confirm the page size and paging style for each list endpoint, since they can differ.
Incident history and updates
Incident history matters most for trust, because subscribers and auditors look back at what happened and when. Pull each incident with its status changes, timestamps and update bodies in order, not only the title and final state. Confirm how far back each listing reaches in your account and whether updates come inline or need a second request per incident. Store the export as JSON, then plan to re-enter or archive the history, and confirm what the Uptime Kuma release you deploy supports for incident posts.
Subscriber exports and consent
The subscriber list is the export most likely to contain personal data, including email addresses and phone numbers used for SMS. Pull it only if you need it, store it encrypted with the same controls as your other personal data, and record whether each contact opted in. Confirm whether the endpoint returns subscription types and the components each subscriber follows, because those filters decide which notifications can be recreated. An export does not, by itself, give you consent to move a subscriber to a new channel.
Rebuilding webhooks and notification channels
Statuspage webhooks and subscriber channels have to be recreated, not copied. Uptime Kuma supports more than 90 notification services, including Telegram, Discord, Gotify, Slack, Pushover and SMTP email, so map each existing channel to one of these or to a generic webhook where the receiving system expects a specific payload. Inventory every consumer of Statuspage webhooks, such as chat channels, ticketing or on-call tools, and test each one from the new installation before you retire the old endpoint. Check the supported list in the Uptime Kuma repository for your version.
Token scope and secret handling
The API token grants access to your status data, and depending on its permissions it may also allow changes. Create a token limited to read operations for the export, keep it in a secrets manager, and revoke it when the migration ends. Log each run with its timestamp, endpoint and record count so you can show what was exported and when. Confirm the current permission model in Atlassian's documentation before you issue the token, because token scopes can change.
Mapping Statuspage components to Uptime Kuma monitors
A Statuspage component is a display item: a name, a status value such as operational or major outage, and a place in a group. An Uptime Kuma monitor is different because it checks something. Each monitor targets a URL or host using one of its check types (HTTP(s), TCP, HTTP(s) keyword, HTTP(s) JSON query, WebSocket, ping, DNS record, push, Steam game server or Docker container), and the result drives the status shown on the page. So the migration is not a one-to-one copy of component names. Before you create anything, list each Statuspage component next to the endpoint or signal that proves it works, such as the /health route behind a customer login, the database port, or a heartbeat sent by a batch job. Components that have no measurable signal, such as a vendor-hosted third-party service, may need to stay as manually managed entries or be left off the page. Confirm in your own environment which check type each one needs, and confirm how Uptime Kuma exposes group names on the status page before you rebuild the layout.
Decide which components become monitors using three questions: can a machine detect failure without a person, does the failure matter to subscribers, and does a single check reflect the service the customer actually uses. A keyword or JSON query check is usually more accurate than a plain HTTP check, because a web server can return a 200 response while the application behind it is failing. Groups in Statuspage, such as an API group containing several endpoints, can be recreated as Uptime Kuma status page groups, with monitors placed under the group that matches the customer's view. Keep the component names that subscribers recognize, even where the monitor is named differently internally, so incident history still reads correctly after the move.
Monitors detect failures, but during a real incident someone usually needs to set a status that the check does not show, such as degraded performance during a partial outage or a planned maintenance window. Statuspage handles this through manual component updates. In Uptime Kuma, define who may change the published state, how the change is recorded, and how it is reverted once the check recovers, and rehearse that process before cutover. Without a written process, a check that shows green while customers report errors can leave the page inaccurate, and a manual override that is never cleared can keep a healthy service marked as down. Document both cases in the runbook you hand to the on-call team.
How the move differs for public, private and multi-page setups
A single public page is the simplest starting point. Most of the work is in the component model and the subscriber list, because there is only one URL that customers already know and bookmark. The cutover is a DNS change on one hostname, and the rebuilt page can run alongside Statuspage while you check it.
- Component mapping: Decide which Statuspage components become Uptime Kuma monitors and which are simply displayed groups with no check behind them. A component that is only a manual status label may need a push monitor or a documented manual update process.
- Incident history: Export past incidents through the Statuspage API and decide how much history to re-create by hand. Recent incidents usually matter more to subscribers than the full archive.
- Subscriber notices: Tell subscribers in advance which address will send updates and confirm that they still have a valid opt-in with the new tool.
- Dry run: Build the page under a temporary hostname first and check layout, group names and status colors before pointing your production domain at it.
Before you cut over, confirm the exact export fields your Statuspage plan returns and the notification channels your team will use on the Uptime Kuma side.
Teams that run several pages for different products, brands or regions usually face the most design work. Uptime Kuma supports multiple status pages, and each status page can be mapped to a specific domain, so the structure can mirror what customers see today. The main task is to decide which monitors belong on which page before anything is rebuilt.
- Page inventory: List every Statuspage page with its domain, components, subscribers and whether it is public or private. Shared components may need to appear on more than one page.
- Domain mapping: Plan one custom domain per status page and confirm the DNS and TLS steps for each hostname in your own environment.
- Shared monitors: A monitor that feeds two pages should be defined once and attached to both, so a single failing check does not produce conflicting statuses.
- Subscriber separation: Keep subscriber lists separate for each brand. Moving one brand's subscribers to another brand's page can break consent and expectations.
- Naming and branding: Check logos, titles and footer text on each page, since a copy-over from one page to another is a common source of errors.
Ask the vendor or your own tests to confirm how custom domains are configured and certificate-managed in the version you deploy.
Internal status pages are the part of the move that needs the most caution. Statuspage private and audience-specific pages restrict access to authenticated subscribers, and that access model does not carry over automatically. Uptime Kuma status pages are designed to be shared publicly, so any internal page needs an access control layer that you put in front of it.
- Access model: Define who should see each internal page, such as employees in a specific group, and map that to groups in your identity provider.
- Identity-provider approach: One option is to place the Uptime Kuma page behind an identity-aware reverse proxy or your identity provider. Treat this as a design to confirm against the chosen deployment rather than a default you can assume works.
- Network placement: Consider whether the internal page should be reachable only from a corporate network or VPN, which can reduce the reliance on a single access layer.
- Audit and evidence: Record who can reach internal pages and how access is granted and removed, because auditors and security reviewers often ask for this.
- Testing: Verify that unauthenticated requests are refused, that group changes take effect, and that the page does not leak component detail through cached or public URLs.
Before relying on this setup, confirm the authentication method, session handling and proxy configuration with a test in your own environment.
Questions teams ask before moving Statuspage to Uptime Kuma
Do subscribers move automatically when we switch to Uptime Kuma?
No. Subscriber lists do not transfer through an export that Uptime Kuma can import, so subscribers must opt in again on the new page. Before you export anything, check how each subscriber was added and whether they consented to receive messages from the new channel. Uptime Kuma's status page notifications run through the notification services you configure, so the list you rebuild depends on which channels you enable, typically email, Slack, Telegram or a webhook. Plan a notice on the old page and a clear opt-in path on the new one, and keep a record of each consent for your own compliance files.
How long does a Statuspage to Uptime Kuma move take, and what drives it?
Duration depends on the number of components, the depth of incident history you need to keep, how many status pages you run, and how many subscriber channels must be reconfigured. Pulling data is usually the shortest step. The longer steps are mapping components to monitors, testing each check against the real service, and running the old and new pages in parallel. Ask any provider for a schedule tied to a written scope, and confirm whether it includes testing against your production endpoints and a DNS cutover window.
What does the work need from our team?
Your team needs to supply access to the Statuspage account and its API token, a list of the services each component represents, owners who can confirm monitor endpoints, and someone who controls DNS for every custom domain. The team also decides which incidents are worth keeping as history and who approves the subscriber notice. Keep a named owner for the status page after launch, because Uptime Kuma will not write incident updates for you unless someone posts them.
Can we do the migration in-house?
Yes, if your team already runs Docker or Node.js services and has someone comfortable with REST APIs and DNS. The Uptime Kuma project provides installation through Docker Compose or a single docker run command with the louislam/uptime-kuma:2 image, and it can run without Docker on Node.js 20.4 or later. The parts teams most often underestimate are the export script, rate-limit handling for the Statuspage API, and rebuilding notification channels. If those are not in your team's skill set, a fixed-scope engagement from DeployOpen can cover planning, implementation and documentation, and ongoing support can be added as a retainer.
How are custom domains and certificates handled on the new status page?
Uptime Kuma supports multiple status pages, and each can be mapped to a specific domain. You must still create the DNS records that point each hostname at your server, and you must provision a TLS certificate for each name using your own process, such as a reverse proxy with automatic certificates. Plan the cutover so DNS changes happen one domain at a time, and confirm that the old Statuspage CNAME records can be removed without breaking subscriber links. Check each certificate's renewal path before you retire the old page.
What should a quote for this migration include?
A useful quote lists each deliverable and the environment it targets: the self-hosted Uptime Kuma deployment, the export and import scripts, the component-to-monitor map, the status page configuration per domain, the subscriber transition plan, DNS and certificate steps, and handover documentation. It should separate one-time work from recurring items such as hosting, upgrades, email and SMS delivery accounts, and any support retainer. Ask who pays for the notification providers, how many status pages and monitors are in scope, and what happens if the Statuspage API limits slow the export. Every quote should follow from a written scope before work starts.
What recurring costs remain after we leave Statuspage?
The main recurring costs are the server or cloud instance that runs Uptime Kuma, the time spent on upgrades and backups, and any paid email or SMS delivery service you choose. Statuspage's subscription fees end, but you take on hosting, patching and monitoring of the status service itself. Hosting outside the infrastructure you monitor is a deliberate design choice that keeps the status page up when your main network is down. Ask any provider to itemize these recurring costs in the quote so you can compare them with your current Statuspage invoice.
What usually goes wrong and how to prevent it
Most failed Statuspage moves fail at the edges: subscribers who were never carried over, exports that stall on limits, monitors that report green while users see errors, cutovers that break HTTPS, and incidents nobody owns. Each card below names one failure and the check that prevents it before you switch DNS.
Subscriber consent lost in the move
Statuspage subscribers opted in to receive updates from your page, not from a new tool. Their email addresses and phone numbers cannot simply be copied into Uptime Kuma and treated as consented. Export only the subscribers whose consent you can document, keep the original opt-in records, and send a notice on the old page asking people to subscribe on the new one. Confirm with your legal or privacy team how consent carries over in each jurisdiction where your subscribers sit.
Export stalled by rate limits
Statuspage's REST API allows one request per second per token. A script that pages through components, incidents and subscribers without pacing will get throttled, and a long export can run past a maintenance window. Build the export with a fixed delay between calls, write each page of results to disk as it arrives so a failed run resumes instead of restarting, and use a dedicated token so other integrations are not affected.
Monitors checking the wrong endpoint
A component that reads Operational on Statuspage may map to a homepage check in Uptime Kuma, which returns 200 while checkout or login fails behind it. Monitors built from component names rather than from the services users actually call give false comfort. Map each component to a check that exercises its user path, using keyword or JSON query monitors where a plain HTTP status is too weak, and test each monitor against a deliberately broken response before you trust it.
DNS and certificate gaps at cutover
Each Uptime Kuma status page can be mapped to its own domain, so every custom domain on Statuspage needs a matching DNS record, a TLS certificate issued for the new host, and a reverse proxy route. Missing any one of these leaves the status page down at the exact moment you need it. Lower DNS record TTLs ahead of the change, issue and test certificates on the new server before the switch, and keep the old Statuspage page live until the new one answers on every domain.
Incident updates with no owner
During an incident, status updates often stall because the person who posted on Statuspage is not the person watching the monitors, and Uptime Kuma sends alerts without anyone assigned to write the public message. Name one incident communications owner and a backup for each status page, write the update templates before cutover, and decide who may publish to which page. Confirm that the notification channels you configure, such as email, Slack or Telegram, reach people outside the engineering team.
What drives the cost and duration of the migration
This table lists the factors that change how much work the move from Statuspage to Uptime Kuma takes, why each one matters and what to request in a written scope. Read it before asking for a quote, because the same page count can cost very different amounts depending on domains, subscribers and notification rework.
| Driver | Why it moves cost or effort | How to keep it down, and what to request in writing |
|---|---|---|
| Number of status pages | Each Uptime Kuma status page is configured separately with its own groups, layout and visibility, so effort grows with the page count. | Consolidate pages where audiences overlap. Request a per-page inventory listing the components and groups on each page. |
| Components and monitor mapping | Each Statuspage component must be matched to an Uptime Kuma monitor type (HTTP(s), TCP, DNS, push and so on), and components without a clear probe need a new check designed. | Map components to existing health endpoints first. Ask the scope to state how many components will be mapped and how unmapped ones are handled. |
| Custom domains per status page | Uptime Kuma can map a status page to a specific domain, so each custom domain needs DNS, TLS certificate and reverse proxy work, and these steps are repeated per domain. | Count domains before scoping and group pages by domain. Ask who owns DNS and certificate renewal, and whether cutover is staged per domain. |
| Subscriber volume and consent | Statuspage subscriber lists cannot be assumed to transfer with consent intact. Re-opting subscribers or running a sign-up flow adds communication and testing work, and volume affects send time and deliverability checks. | Ask whether subscribers are exported and whether consent records come with them. Request a plan for re-subscription through the new page instead of a bulk import. |
| Notification channel rework | Email, SMS and webhook notifications from Statuspage must be rebuilt in Uptime Kuma's notification services (over 90 supported), each with its own credentials and sender setup. | List every active channel and provider. Ask for the notification rework to be scoped channel by channel, including who holds the SMTP or SMS credentials. |
| Internal SSO or private pages | Private status pages behind single sign-on need identity provider integration, group mapping and access testing, which Statuspage's audience-specific pages handle differently. | Decide early which audiences need internal pages. Request the identity provider, test accounts and the access matrix in the written scope. |
| Historical incident export | Incident history is pulled through the Statuspage API, which is limited to one request per second per token, so large histories take longer to export and to verify. | Estimate history size before scoping. Ask whether the export includes only recent incidents or the full archive, and who reviews the imported records. |
| Testing and cutover window | Each page needs functional, mobile and DNS checks, plus a rehearsal of the switch. Parallel running of both pages extends the window. | Ask for a written test plan and a rollback step per domain. Agree in writing when the old Statuspage stays live and how long it runs in parallel. |
Running Uptime Kuma inside your own infrastructure
Uptime Kuma is released under the MIT license, so the software itself carries no per-monitor, per-subscriber or per-seat fee. You can install it in one of two supported ways. The first is Docker Compose or a single docker run command using the louislam/uptime-kuma:2 image, which suits teams that already operate containers. The second runs the application directly on Node.js 20.4 or later with Git, optionally supervised by pm2, which suits hosts where containers are not permitted. Either way, you run a small, always-on server that you patch, secure and sign into yourself. Confirm with your platform team which option your hardening baseline allows before you choose, because the container image and the Node.js host follow different patching paths.
The recurring work starts with upgrades. The current line is 2.x, and the 2.5.6 release was published on October 9, 2026. Check the Uptime Kuma releases page before each change and read the notes for breaking changes. Test every upgrade against a copy of your monitor data first. Backups come next: copy the data volume or application data directory on a fixed schedule, and restore one copy into a scratch instance to prove it works. Take a fresh backup before each upgrade. Also record which notification providers, such as SMTP or Slack, are configured, so they can be re-entered quickly if a restore is needed.
Two decisions determine whether the status page stays trustworthy. First, monitor the monitor: run an independent check against the Uptime Kuma instance from a location outside it, and make sure a named person is alerted if Uptime Kuma itself stops responding. Second, host the instance outside the systems it watches. If the status page shares a cluster, cloud account or region with the services it reports on, one outage can take down both the monitored service and the page that should explain it. Place the instance in a separate network or account, and keep the DNS records and TLS certificates for each status domain under a process you control. Ask your team who patches the host, who renews certificates and who is on call for the monitor itself.
How DeployOpen scopes and runs the migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For this migration we agree the scope in writing first, then move your status pages, components and incident history to Uptime Kuma on your own domains with a tested subscriber communication plan.
How we scope
- Inventory every Statuspage public and private page, its custom domain and its component list before any work starts.
- Agree in writing which incident history, subscriber records and maintenance data are exported and which are retired.
- Define the component-to-monitor mapping, notification channels and the DNS cutover window as written deliverables.
- Engagements are fixed-scope, and ongoing support can be added later as a retainer.
How we build
- Install Uptime Kuma in your environment with Docker Compose or Node.js, using the louislam/uptime-kuma:2 image or a supported non-Docker setup.
- Pull components and incident history through the Statuspage API while staying within its one request per second limit per token.
- Create one Uptime Kuma status page per Statuspage page and map each custom domain, then test rendering and TLS on staging hostnames.
How we hand over
- Deliver a runbook covering the component-to-monitor map, alert routing, backup of the Uptime Kuma data and upgrade steps.
- Document the subscriber notice, the cutover checklist and the rollback path so your team can repeat or audit each step.
- Walk your operations and communications staff through publishing an incident and maintenance notice on the new pages.
How we support
- Keep a post-cutover review window in the written scope to confirm monitors, status pages and notifications behave as expected.
- Plan backups and version upgrades of Uptime Kuma, checked against its GitHub releases before each change.
- Offer continuous testing or ongoing support as a retainer if your team wants DeployOpen to keep operating the status page stack.
