What happened
DeepSeek moved its public status page, status.deepseek.com, from Atlassian Statuspage to Flashduty Statuspage.
Nobody looks at a status page until something breaks. When it does, it's the one channel still talking to the outside world, and users, media, and customers all refresh it first. So it isn't a throwaway display page, and it's worth picking deliberately. Here's the actual math behind this migration.
Why switch to Flashduty
The three things that actually moved the decision:
Chinese. Atlassian Statuspage's public page has no native Chinese; you'd bolt on a third-party localization integration (like Localize) to fake it. Most of DeepSeek's users read Chinese, and an English-only status page doesn't fly. Flashduty supports Chinese natively, with a language switch and bilingual component names like "API 服务 (API Service)", so one page serves both audiences.
Cost goes to roughly zero. Atlassian Statuspage is a standalone product priced by subscribers, components, and team members; a public page plus an internal page runs into the thousands of dollars a year. Flashduty's status page is included in On-call: if you already run On-call, it costs nothing extra. The only usage-based cost left is email delivery.
Modern UI. Dark mode, rendering performance, global access acceleration — table stakes today. For a page like DeepSeek's, anything slow, blurry, or unreachable from abroad gets noticed. Flashduty's status page is current on all of this, not a decade-old ops console packed with widgets.
The finer feature gaps (maintenance events that don't count against uptime, per-incident subscriptions, component display control, bulk subscriber import/export) and the pricing math are in the status page comparison doc; I'll leave them there.
Why not build your own
Show an engineer a status page and the first reaction is usually "I could write that myself." Scope it as a real project, though, and three things don't pencil out.
Trust. A status page is for outsiders, and hosting it on a third party that's independent of you is inherently more credible than hosting it on your own servers. When you're down, nobody has to wonder whether you're grading your own homework, or whether the status page went down with everything else. Self-hosting can't give you that by construction.
Deploy and maintenance cost. A status page isn't a static page. Do it properly and you're building subscription management, email delivery, availability stats, incident timelines, internal pages — all of which someone has to write and then maintain and iterate on indefinitely. For most teams this isn't core business, so that engineering time is pure cost.
Some things you can't backfill fast. Email reputation is the clearest: reliably delivering to tens of thousands of subscribers rides on IP and domain reputation, SPF/DKIM/DMARC, and bounce/complaint handling built up over time — short of that, you're in spam folders. Then there's the traffic spike: a status page is quiet until an incident, when everyone hits it at once and the peak often beats your normal load. Neither is a few-more-lines-of-code problem; both are a function of time and scale.
Does it migrate cleanly
Yes. DeepSeek's was a migration, not a rebuild.
Two steps through the Flashduty CLI. flashduty statuspage migrate structure imports components, groups, incident history, and notification templates without touching subscribers; once you've checked the structure and history in the console, flashduty statuspage migrate email-subscribers imports subscribers in active state, no re-verification email. Then point your custom domain's CNAME over and go live.
RSS subscribers don't move: Flashduty is compatible with Atlassian's history.rss / history.atom formats, so old URLs keep resolving. Command arguments and the full sequence are in the migration section of the status page comparison doc.
Summary
Pull the migration apart and the logic is simple: the old status page had no Chinese and most users read Chinese — that alone justifies the switch. Moving also took a few-thousand-dollar annual line item down to roughly zero (just usage-based email left) and brought the UI up to date. Building your own looks cheaper until you price in trust, maintenance, and email reputation, none of which come free; easier to hand it to something already wired into On-call. The migration itself is two commands, and subscribers never notice.
If you're on Atlassian Statuspage and your users mostly read Chinese, you can copy this path directly.
Related docs:
