Atlassian Statuspage Guide: Incident Communication That Builds Trust

When your service goes down, you have two failure modes. The first: your users discover the outage, flood your support channels, and spend 20 minutes wondering if the problem is on their end before you acknowledge anything. The second: they check your status page, see a clear incident acknowledgment with a timeline, and wait with appropriate expectations.

The difference isn't just about customer experience. It's about operational load during the worst moments. A status page that customers can check removes the manual work of answering "is it just me?" for every affected user.

Atlassian Statuspage is the most widely used dedicated status page tool. This guide covers how to build one that actually communicates well during incidents, not just one that exists.

What Statuspage Is

Statuspage is a product built specifically for communicating service status to external users. Atlassian acquired it in 2016 and integrated it into their broader product suite, though it functions independently from Jira and Confluence.

The core use case: a public-facing page where customers can see whether your services are operational, view current and past incidents, and subscribe to receive notifications when things change.

Unlike monitoring tools (UptimeRobot, Freshping), Statuspage doesn't check your services itself. It's a communication layer — the display and notification system for status information that your monitoring tools or your team provide. You update it; it broadcasts those updates to subscribers.

Pricing and Plans

Statuspage's pricing has changed over the years and now has several tiers:

Free (Hobby) — 1 status page, up to 100 subscribers, basic features. Suitable for open-source projects or very small teams.

Starter — ~$29/month, 500 subscribers, unlimited team members.

Team — ~$79/month, 1,000 subscribers, custom domain, custom CSS.

Business — ~$199/month, 10,000 subscribers, metrics, private pages.

Enterprise — Custom pricing, unlimited subscribers, advanced features.

The subscriber limit is the main constraint at lower tiers. A growing SaaS product with thousands of users will need a paid plan for adequate subscriber capacity.

Building Your Status Page

Account Setup and Page Creation

Create an account at statuspage.io (now part of atlassian.com/software/statuspage). You can sign in with an Atlassian account. Creating your page is the first step — one account can manage multiple status pages.

Give your page a name (usually your company or product name) and a subdomain (yourcompany.statuspage.io). You'll configure a custom domain later if you want status.yourcompany.com.

Defining Components

Components are the services, features, or infrastructure pieces you'll communicate status about. This is the most important design decision when setting up Statuspage.

The mistake most teams make: defining components based on their internal infrastructure rather than on user-visible functionality.

Your users don't know what "us-east-1 production cluster" means. They know whether they can log in, whether their dashboard loads data, whether they can submit orders.

Component naming principles:

• Use customer-facing language, not internal names
• Describe what the user can do, not what system supports it
• Keep names short and unambiguous

Examples of bad component names:

• api-server-prod
• postgres-primary
• redis-cache-us-east

Examples of good component names:

• API
• Dashboard
• User Authentication
• File Uploads
• Checkout & Payments
• Email Notifications

Each component has four possible statuses: Operational, Degraded Performance, Partial Outage, and Major Outage. You update these manually (or via API) when the status changes.

Component Groups

If you have many components, groups help organize them logically. Groups appear as sections on the status page:

Group: Core Features

• Login & Authentication
• Dashboard
• Reports

Group: Integrations

• Slack Integration
• Zapier Integration
• API

Group: Infrastructure

• API
• CDN
• Database (if customer-visible)

Groups are useful when your product has distinct functional areas that different customer segments care about. They're not necessary for simple products with a few components.

Metrics Display

Statuspage can display real-time and historical metrics on your status page — response times, error rates, or any numeric metric you provide.

You can connect metrics from:

• Pingdom (native integration)
• Datadog (native integration)
• New Relic (native integration)
• Custom API — POST metrics to the Statuspage API from any source

What metrics to display:

Display metrics that customers care about and that you're willing to be accountable to. API response time is a good choice — it's meaningful to developers using your API. Internal database query time is not a good choice — it's infrastructure detail customers don't need.

Common useful metrics:

• API response time (p50 and p95)
• Request success rate / error rate
• CDN performance
• Background job processing time (if customer-visible)

Don't add metrics just to have them. A sparse status page with well-chosen metrics looks better than a cluttered one with metrics nobody understands.

Subscriber Notifications

Subscriber management is one of Statuspage's core features. Users can subscribe to receive notifications when incidents are created, updated, and resolved.

Subscription Channels

Email — Subscribers enter their email address on your status page. They receive email notifications for incidents affecting components they subscribe to.

SMS — Available on higher-tier plans. Subscribers enter their phone number for SMS alerts.

RSS/Atom — A feed URL for users who prefer RSS readers. Also useful for programmatic consumption.

Webhook — Users or applications can provide a webhook URL to receive real-time notifications as JSON payloads.

Slack — Statuspage provides a "Subscribe via Slack" option that posts updates to a Slack channel.

Component-Level Subscriptions

Subscribers can choose which components they want notifications about. A customer who uses only your API doesn't want notifications about your Dashboard being degraded.

This granularity is one of Statuspage's strongest features. Well-segmented subscriptions reduce notification fatigue, which means subscribers pay attention when they do receive notifications.

Encourage targeted subscriptions: On your status page, prompt users to select only the components relevant to them. "Subscribe to all" is convenient but leads to notification fatigue.

Managing Subscribers

The Statuspage dashboard shows your subscriber count and lets you view/export the list. You can manually add subscribers for key customers or enterprise accounts — useful when you want to ensure specific customers receive notifications without requiring them to opt in.

Incident Workflow

This is where Statuspage's value shows up most clearly. The incident workflow is the communication protocol for when things go wrong.

Creating an Incident

When a service issue occurs, create an incident from the Statuspage dashboard:

1. Name the incident — Use a description that's meaningful to users. "API Degraded Performance" or "Dashboard Login Issues" rather than "Incident #847."
2. Set the status — Investigating, Identified, Monitoring, Resolved. Each maps to a stage in your response process.
3. Write the incident message — This is what subscribers see. Write it for a non-technical audience. More on this below.
4. Select affected components — Choose which components are impacted and update their status to reflect the severity.
5. Publish — Click "Create." Subscribers receive notifications immediately.

Incident Statuses Explained

Investigating — You know something is wrong. You don't know why yet. Use this the moment you detect an issue, even before you understand the cause. Early acknowledgment reduces customer anxiety.

Identified — You've determined the cause. You know what's broken and have a plan. Update to this status when you understand the problem.

Monitoring — You've implemented a fix and are watching to ensure it holds. The issue may be resolved but you're not fully confident yet.

Resolved — The incident is over. Everything is operational. Post a clear resolution message.

Writing Good Incident Updates

This is where most teams fail. Incident updates are customer-facing communication, not technical documentation.

What to avoid:

• Technical jargon your customers don't understand
• Internal terminology (service names, server identifiers)
• Vague language ("some users may be experiencing issues")
• False certainty about ETAs you don't have

What to write:

Opening update (Investigating): "We are aware of an issue affecting [component]. Some users may be unable to [specific action]. We are actively investigating and will provide an update within 30 minutes."

After identifying root cause: "We have identified the cause of the issue affecting [component]: [plain-language description]. Our team is implementing a fix. We expect to have this resolved by [time] and will provide updates every 30 minutes."

Resolution: "This incident has been resolved. [Component] is now operating normally. All users should be able to [affected action] again. We apologize for the disruption and will post a follow-up summary within 24 hours."

Update frequency: Post updates every 20-30 minutes during active incidents, even if you have nothing new to report. "We are continuing to investigate and have no new information to share. We will update again in 30 minutes." Silence during a long incident is worse than a progress-free update — at least subscribers know you're still working on it.

Scheduled Maintenance

Statuspage handles planned maintenance through a separate flow. You create a "Scheduled Maintenance" notice with:

• Start and end time
• Description of what's planned and what will be affected
• Components that will be impacted

Subscribers receive advance notification (configurable: 1 day, 1 week, etc. before the window) so they can plan around it.

This is important for SLA-sensitive customers who need to know about planned downtime in advance. Treating scheduled maintenance the same as unplanned incidents (no advance notice) is a customer relationship problem.

Embedding Statuspage in Help Documentation

A status page only helps if customers can find it. Beyond publishing the URL, Statuspage provides an embed feature that lets you display your current status inside other pages.

The Status Embed Widget

Statuspage generates a JavaScript snippet that displays your current operational status as a badge or banner:

<script src="https://[your-page].statuspage.io/embed/script.js"></script>

This badge shows:

• "All Systems Operational" with a green indicator when everything is fine
• The current incident description with a yellow or red indicator when something is wrong

Where to embed it:

Your help center / documentation — The most impactful placement. When users search your documentation looking for why something isn't working, they immediately see current system status.

Your main application UI — A small status indicator in a corner of your app UI, visible to logged-in users. When things are broken, users see acknowledgment before reporting a bug.

Your login page — When authentication is broken, users trying to log in should see that you're aware of the issue.

Your marketing site — Some teams embed status on the homepage footer. Less critical, but demonstrates transparency.

The API for Custom Integrations

Statuspage has a REST API for every action: creating incidents, updating component statuses, managing subscribers, posting metrics. This enables:

Automated incident creation — When your monitoring tool (Datadog, PagerDuty, custom alert) fires, automatically create a Statuspage incident via API. This is much faster than requiring a human to manually post a status update while simultaneously responding to an incident.

Automated component status updates — Based on your monitoring data, automatically update component statuses to reflect current performance.

Custom subscriber management — Programmatically subscribe enterprise customers, manage subscription preferences, or integrate subscription with your user onboarding flow.

Integrations with Monitoring Tools

Statuspage integrates with common monitoring and incident management tools:

PagerDuty — When a PagerDuty incident is created, automatically create a Statuspage incident and update it as the PagerDuty incident progresses.

Datadog — Sync monitor status to Statuspage components. When a Datadog monitor alerts, the corresponding component status updates automatically.

Opsgenie — Similar to PagerDuty integration.

Jira — Link Statuspage incidents to Jira issues for tracking.

Zapier/Webhooks — Connect to any tool through webhooks for custom workflows.

The automated integrations are valuable because they reduce the human action required during incident response. The fewer manual steps between "monitoring detects issue" and "status page updated," the faster your communication.

Common Mistakes to Avoid

Updating too slowly. A status page that customers check during an incident and find "All Systems Operational" while they can't log in is worse than no status page. Staleness destroys trust faster than the incident itself.

Writing for engineers, not customers. "Postgres replica lag is causing read query timeouts" is informative internally. To a customer, "Dashboard data may be delayed or temporarily unavailable" is clearer and more actionable.

Only updating at the start and end. Radio silence for an hour during a major incident while customers wait is a customer service failure. Intermediate updates acknowledging continued work matter even when there's no new information.

Listing too many components. A status page with 30 components is overwhelming. Include only what customers interact with directly. Infrastructure that supports your services but isn't customer-visible doesn't need to appear.

Not linking to your status page from anywhere. Publish the URL in your application, documentation, and support templates. Your status page helps nobody if customers can't find it when they need it.

Functional Testing Alongside Status Communication

Statuspage handles communication during incidents. It doesn't detect whether your application is functionally correct — that's a separate problem.

A status page tells customers what's happening. Functional testing tells you what's broken before customers experience it. Tools like HelpMeTest run automated browser tests against your application to verify that real user workflows — login, key actions, critical paths — work correctly. When those tests fail, you have an issue to communicate via your status page.

The combination is: monitoring and functional testing as the detection layer, Statuspage as the communication layer. Detection without communication leaves customers uninformed. Communication without detection means your status page is always "All Systems Operational" until customers tell you otherwise.

Conclusion

Statuspage is the standard tool for status page communication because it's genuinely good at the thing it does: structured incident communication to external audiences.

The value isn't the technology — it's the operational discipline it creates. Having a status page means you have an established workflow for communicating during incidents. You know where to post updates, subscribers know where to look, and the process happens whether or not the person handling the incident remembers to draft an email.

Set it up before you need it. Define your components thoughtfully. Build the integration with your monitoring tools. Embed the status widget in your help docs. Then, when something breaks, you'll be able to communicate clearly and quickly instead of improvising while also fixing the problem.