# We're Relaunching StatusDashboard A rebuilt platform, a clearer admin experience, and a public status page you're proud to share. Here's what's changing and why we think you'll feel the difference. Date: 2026-08-16 Author: The StatusDashboard Team Source: https://statusdashboard.com/blog/relaunching-statusdashboard We've spent the last year rebuilding StatusDashboard from the ground up. Today we're relaunching the platform, not as a coat of paint on the old product, but as a modern foundation for how teams communicate reliability. If you've used StatusDashboard before, some of this will feel familiar. A lot of it won't. This post covers what's changing and why. We will publish deeper guides on the blog in the weeks ahead. > **Existing customers:** Your live status dashboards keep running. Nothing changes for you today. Our customer support team will contact each account directly for migration support in the coming months. Questions now? [Reach out to support](/contact). ## The short version | | Previous experience | Relaunched platform | | --------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | **Admin app** | Functional, but dated workflows | Refreshed UI with light/dark mode and faster paths to declare incidents and post updates | | **Status pages** | Reliable public pages | Richer branding, component modeling, and subscriber signup flows | | **Themes** | Mostly fixed light styling | Light/dark mode on public pages, with your brand accent color carried through | | **Accessibility** | Uneven assistive support across surfaces | Fully accessible public status page: keyboard navigation, screen readers, and semantic structure throughout | | **Notifications** | Primarily email-centric | Refreshed email, SMS, Slack, Teams, Google Chat, and webhooks | | **Subscriber emails** | Basic templates with platform-default footers | Compliance-ready footers, polished templates, and reliable rendering across more email clients | | **API** | Limited surface area | Full REST API mirroring what you can do in the app | | **Enterprise** | Add-on feel | SSO, roles, audit, whitelabel, and post-mortem follow-ups as first-class paths | | **Documentation** | Scattered | Unified docs, API reference, and release notes at `/docs` | That's the headline. The sections below unpack *how* and *why*. ## Why we rebuilt instead of patching Status pages sit in an uncomfortable spot: they must be **boringly reliable** when nothing is wrong and **loudly clear** when something is. The old platform did the job, but every incremental feature fought the original architecture. We wanted: 1. **One coherent data model** for components, events, timelines, and subscribers, so a single update propagates everywhere it should. 2. **An admin experience** that matches how on-call teams actually work under pressure: fewer clicks to declare, update, and resolve. 3. **Public surfaces** (status page, email, chat) that stay in sync without manual copy-paste. 4. **An API** that automation engineers can trust for the next decade of integrations. Relaunching let us make those bets without dragging years of compromise forward. ## Three things you'll notice immediately Declare incidents, post timeline updates, and resolve, with notifications wired in from the start. Less hunting, more communicating. Custom domains, branding, component groups, and subscriber signup flows that look like they belong on your site, not a generic template stapled on. Email is still table stakes. Now add SMS, Slack, Teams, Google Chat, and outbound webhooks so updates meet customers where they already work. ## What's better, area by area ### For operators and support | Capability | What's improved | | ----------------------- | ------------------------------------------------------------------------------------------------------------- | | **Event timelines** | Structured status history with clear resolve/reopen semantics: a durable record for post-incident review | | **Maintenance windows** | Schedule ahead, notify subscribers, and show planned work distinctly from unplanned incidents | | **Roles & permissions** | Invite the right people with the right access. Support, engineering, and admins aren't forced into one bucket | ### For security and compliance | Capability | What's improved | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | **SSO** | SAML and OIDC as first-class admin configuration: domain mapping, enable/disable, and break-glass paths when IdP access fails | | **Roles & permissions** | Clear admin vs. user boundaries: who can change org settings, billing, status dashboards, and events | | **Audit log** | Always-on, searchable record of meaningful app, API, and automated activity: who did what, and when | | **Subscriber email compliance** | Tenant mailing address and branded footers on subscriber emails; polished templates built to render reliably across major clients (including Outlook) | | **Deliverability controls** | Organization-wide suppression list and delivery logs for bounces and complaints, so you can protect reputation without guessing | | **Subscribe spam protection** | reCAPTCHA on public status dashboards (SSO off) for subscribe and manage-request flows, which cuts bot signups and keeps subscriber lists cleaner | | **Dashboard access controls** | Per-dashboard IP allowlist when a status page should be internal-only (office, VPN, egress IP) | | **Public vs. private metadata** | Event attributes that stay in the editor. Internal ticket IDs and runbook links don't leak to public status pages or subscriber notifications | ### For your customers and subscribers | Capability | What's improved | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Component clarity** | Show *which* part of the product is affected (API vs. web app vs. a region), not a single red bar for everything | | **Accessibility** | Public status pages built with semantic HTML, keyboard navigation, visible focus, and contrast-aware design aligned with WCAG, so outage updates stay readable for every visitor | | **Subscription options** | Let visitors choose components and channels; reduce noise, increase relevance | | **In-dashboard help** | Short guides on the status page for email, SMS, Teams, Google Chat, and webhooks: how to subscribe, verify, and manage preferences | | **Notification formatting** | Richer emails and chat messages that link back to the live timeline | | **Post-mortem reports** | Structured follow-up on incidents and maintenance: publish when ready, unpublish without losing the draft | ### For engineers and integrators | Capability | What's improved | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | **REST API** | Create and manage components, events, timelines, subscribers, and more. [Documented at `/docs/api`](/docs/api) | | **Custom domains & SSL** | Self-service provisioning for status dashboards, custom domains, and SSL certificates. Add your DNS record and go live without opening a support ticket | | **Inbound webhooks** | Turn external alerts into incidents without building a custom bridge first | | **Outbound webhooks** | Push status changes into your own automation stack | > **Questions or feedback?** We built this relaunch around how teams actually run incidents. If something does not work the way you expect, or you have a suggestion, [reach out to support](/contact). We read every message. ## What's *not* changing Some principles carry over because they were already right: * **Transparency during incidents** is non-negotiable. The product still exists to make the official story easy to find. * **Your brand on your domain.** Whitelabel and custom domains remain central, not premium afterthoughts. * **Secure, reliable hosting.** Same commitment to security and operational discipline outlined in our [Trust & Security](/security) materials. ## If you're an existing customer We're treating relaunch as a **guided transition**, not a hard cutover. **Your status dashboards stay live.** Keep using StatusDashboard as you do today. Your data, subscribers, custom domains, and public status pages are unchanged. **Our customer support team will reach out to every account.** In the coming months, we will contact you directly for migration support. You will not need to piece together the plan from blog posts. | Phase | What to expect | | ------------------- | ------------------------------------------------------------------------------------------- | | **Today** | No disruption. Continue on your current setup while new signups use the relaunched platform | | **Your migration** | Direct outreach from our support team with guidance for your account | | **After migration** | Single platform, unified docs, predictable API versioning | Questions in the meantime? [Reach out to support](/contact). We will walk you through what relaunch means for your account. ## Stay in the loop We'll use this blog for product updates, guides, and release notes. If there is a topic you want covered, [reach out to support](/contact) and tell us what would help your team. > **New here?** [Start a free trial](https://app.statusdashboard.com) and follow the [Quick Start](/docs/quick-start). Most teams have a credible first status page live in one sitting. *** The relaunch isn't a marketing moment for us. It's a promise: when something breaks, your customers get clarity, and your team gets a system that helps instead of fights you. We're glad you're along for the rebuild. Tell us what you need next.