# The status page should answer who is affected before support opens > Why maintenance reminders, uptime history, segmented pages, regional sub-pages, and customer-only status views turn incident comms into a trust surface. - Canonical HTML: https://growth.iangoh.com/blog/the-status-page-should-answer-who-is-affected-before-support-opens/ - Published: 2026-05-29 - Updated: 2026-05-29T12:35:00Z - Categories: brand trust, support-led growth, operations - Niches: SaaS, developer tools, AI products, B2B software, infrastructure tools ## On this page - Planned downtime should not feel like surprise downtime - A reliability claim should have a page behind it - Most status pages talk to too many people at once - Local incidents should stay local - Important accounts often need their own answer ## Start with these related tactics - [Scheduled maintenance reminder before the window opens](/growth-ideas/scheduled-maintenance-reminder-before-the-window-opens/): Publish planned maintenance on the status page early enough that subscribers get both the announcement and the one-hour reminder before the work starts. - [Ninety-day uptime history on the public status page](/growth-ideas/ninety-day-uptime-history-on-the-public-status-page/): Turn on public uptime history so buyers and customers can see the last 90 days of reliability without booking a reassurance call. - [Audience-specific status page by cluster or tier](/growth-ideas/audience-specific-status-page-by-cluster-or-tier/): Split the status experience by customer group, shard, or plan so each audience only sees the components and alerts that actually matter to them. A status page is usually treated like the place you apologize after something has already gone wrong. That is too small a job for it. In practice, the page is doing sales, support, and trust work at the same time. Buyers check it during diligence. Customers check it when they are nervous. Customer success checks it before they write back. The useful question is not whether you have a status page. It is whether the page answers the first real question fast. That first question is usually simple: does this affect me? ## Planned downtime should not feel like surprise downtime [Scheduled maintenance reminder before the window opens](/growth-ideas/scheduled-maintenance-reminder-before-the-window-opens/) matters because many outages are social before they are technical. The work may be planned, but if the customer discovers it in the middle of their own launch or reporting run, it still lands like negligence. Atlassian's maintenance flow is practical here: the maintenance can show up on the page early, notify subscribers immediately, and send a reminder an hour before it starts. That reminder does not fix the downtime. It fixes the feeling that the company forgot the customer had a schedule too. It also pairs naturally with [dedicated status domain before first incident](/growth-ideas/dedicated-status-domain-before-first-incident/), because the warning only helps if the page is easy to reach when the moment arrives. ## A reliability claim should have a page behind it A lot of companies talk about uptime in sales calls and then show nothing in public except a blank all-systems-operational banner. [Ninety-day uptime history on the public status page](/growth-ideas/ninety-day-uptime-history-on-the-public-status-page/) is better because it gives support, sales, and buyers the same visible record. A page that shows the last 90 days of component history is more useful than a promise that things are usually fine. This is where the status page starts pulling weight outside incident response. It becomes a self-serve proof surface, much like [public postmortem linked from resolved incident](/growth-ideas/public-postmortem-linked-from-resolved-incident/). One page shows how often things went wrong. The other shows how the company explains itself when they do. ## Most status pages talk to too many people at once Generic incident pages create a lot of unnecessary fear. [Audience-specific status page by cluster or tier](/growth-ideas/audience-specific-status-page-by-cluster-or-tier/) is useful because it lets each audience see only the components and alerts that belong to them. That matters for single-tenant setups, customer shards, plan-specific infrastructure, and internal teams who need a different view from the public one. The same logic shows up in [component-level status subscriptions before broad blasts](/growth-ideas/component-level-status-subscriptions-before-broad-blasts/). The cleaner the scope, the less likely the message turns into background noise. ## Local incidents should stay local [Regional or product sub-pages for incident scope](/growth-ideas/regional-or-product-sub-pages-for-incident-scope/) makes the point plainly. If a North America component is having trouble, Europe does not need to feel like the whole company is on fire. incident.io's sub-pages let teams keep one operating system behind the scenes while still publishing the incident only where the affected components are visible. That is not just cleaner support writing. It is product communication with less collateral damage. ## Important accounts often need their own answer The highest-value customers are often the least well served by a public catch-all page. [Customer-specific status page for dedicated infrastructure](/growth-ideas/customer-specific-status-page-for-dedicated-infrastructure/) is worth stealing when a subset of customers runs on separate systems or carries unusually high revenue risk. An authenticated customer page gives account teams one precise link to send instead of a paragraph that starts with "this may not affect you." For SaaS, developer tools, AI products, B2B software, and infrastructure tools, the lesson is simple. A status page should not only say whether the system is up. It should help the right person understand what changed, whether they should care, and where to look next. If you want help turning reliability surfaces into cleaner trust and growth assets, the advisory CTA is here: [work with Ian Goh](https://iangoh.com/advisory). ## Related GrowthDex tactics - [Scheduled maintenance reminder before the window opens](/growth-ideas/scheduled-maintenance-reminder-before-the-window-opens/) - Lifecycle, Support, Brand - [Ninety-day uptime history on the public status page](/growth-ideas/ninety-day-uptime-history-on-the-public-status-page/) - Brand, Sales, SEO - [Audience-specific status page by cluster or tier](/growth-ideas/audience-specific-status-page-by-cluster-or-tier/) - Support, Lifecycle, Sales - [Regional or product sub-pages for incident scope](/growth-ideas/regional-or-product-sub-pages-for-incident-scope/) - Support, Brand, Product - [Customer-specific status page for dedicated infrastructure](/growth-ideas/customer-specific-status-page-for-dedicated-infrastructure/) - Sales, Customer Success, Support ## Essay chronology - [Newer essay: The help article should know what comes next](/blog/the-help-article-should-know-what-comes-next/) - SEO, support-led growth, brand trust - [Older essay: The next step should already be there](/blog/the-next-step-should-already-be-there/) - product-led growth, onboarding, SEO ## Keep reading - [The customer-facing answer should keep the context attached](/blog/the-customer-facing-answer-should-keep-the-context-attached/) - support-led growth, brand trust, customer success - [The answer should travel before the queue grows](/blog/the-answer-should-travel-before-the-queue-grows/) - support-led growth, brand trust, SEO - [The support queue should know what kind of thread it is](/blog/the-support-queue-should-know-what-kind-of-thread-it-is/) - support-led growth, community-led growth, brand trust ## Continue through the blog - [SaaS](/blog/#path-saas) - 3 essays in this path - [AI products](/blog/#path-ai-products) - 3 essays in this path - [developer tools](/blog/#path-developer-tools) - 3 essays in this path ## Sources - [Atlassian Statuspage Docs: Schedule maintenance](https://support.atlassian.com/statuspage/docs/schedule-maintenance/) · [GrowthDex source hub](/sources/atlassian-statuspage-docs-schedule-maintenance-support-atlassian-com/) - [Atlassian Statuspage Docs: Display historical uptime of components](https://support.atlassian.com/statuspage/docs/display-historical-uptime-of-components/) · [GrowthDex source hub](/sources/atlassian-statuspage-docs-display-historical-uptime-of-components-suppor/) - [Atlassian Statuspage Docs: What are audience-specific pages?](https://support.atlassian.com/statuspage/docs/what-are-audience-specific-pages/) · [GrowthDex source hub](/sources/atlassian-statuspage-docs-what-are-audience-specific-pages-support-atlas/) - [incident.io Docs: Setting up sub-pages](https://docs.incident.io/en/articles/8391002-setting-up-sub-pages) · [GrowthDex source hub](/sources/incident-io-docs-setting-up-sub-pages-docs-incident-io/) - [incident.io Docs: Introduction to status pages](https://docs.incident.io/status-pages/overview) · [GrowthDex source hub](/sources/incident-io-docs-introduction-to-status-pages-docs-incident-io/) ## Editing notes - Kept the piece on one practical claim: the status page earns trust when it answers scope and relevance quickly. - Used ordinary scenes like a customer mid-launch, a diligence check, and an account team sending one precise link instead of abstract resilience language. - Let the source mechanics carry the proof instead of turning incident communication into grand brand philosophy. - Closed on the operational lesson and advisory CTA rather than a generic reliability sermon. ## Advisory If you want help turning this into a growth system, Ian Goh offers advisory at https://iangoh.com/advisory.