Internal status page and private status page for employees, support and IT

An internal status page is a private page that tells your own people (support, sales, account managers, the service desk and the rest of the company) which systems are down and what engineering is doing about it. In IncidentBot the private page is fed by the incident itself: responders publish an update from Slack or the web app and every employee with the page link sees it, without a separate tool, a seat per reader or a cap on viewers.

The result is fewer "is it just me?" messages in #engineering, fewer duplicate tickets at the service desk and support agents who can answer customers with the same facts the incident commander has.

Run a sample incident

Why teams set up a private status page

Engineer checking a test page notification on a phone next to a laptop

During an outage the people who are not fixing it still need answers. Support gets 40 tickets about the same error, sales wants to know if the demo at 2 p.m. is safe, and an executive asks in a DM whether to tell the board. Every one of those questions lands on the engineers who are trying to restore service.

A private page sits between the two. It shows confirmed, plain-language updates for the systems your company depends on, it updates in one place and every reader sees the latest version.

The public page says too little. It is written for customers, so it leaves out the internal systems (VPN, SSO, the CRM, the billing job, the data warehouse) that employees care about most.
The incident channel says too much. Forty people reading a war room slows down the responders, and half of what is posted there is guesswork that should not be repeated to a customer.
Statuses in DMs go stale. A summary pasted into five Slack threads at 10:14 is wrong by 10:40, and nobody goes back to correct it.

Who reads an internal status page

Customer support and success, who need a confirmed answer and an expected next update time before they reply to a ticket.
IT service desk agents, who can point employees to the page instead of opening one ticket per person for the same VPN or SSO outage.
Sales and account managers with enterprise customers who ask for a direct heads-up.
Leadership, who want to know the impact and the next step without joining the incident channel.
Enterprise customers, if you share a dedicated private page with them instead of the public one.

A private page updated from the incident, not typed twice

On-call engineers reviewing an escalation plan together at a shared desk

Because the internal page and the customer page read from the same incident, they never contradict each other. The internal one can simply carry more systems and more detail.

An alert from Datadog, Prometheus Alertmanager, Grafana, CloudWatch, Sentry, email or a webhook pages the on-call engineer through your escalation policy.
The responder declares an incident with /incident in Slack or in the web app, and picks the affected services.
The comms lead writes the update once. A person presses publish, so nothing reaches readers on its own, and the raw alert text never appears on the page.
Every status page that lists those services shows the update: the private page for employees, and the public page for customers if the incident affects them too.
People who subscribed to the page get the update by email, and every published update is written to the incident timeline for the incident postmortem.

How access to the private page works

Each private page has its own address with a long secret access key. Anyone you give the link to can read it, and anyone without it gets a not-found page. Private pages are never listed in the sitemap and tell search engines not to index them. Most teams put the link in the intranet, the service desk portal or a pinned Slack message, so access follows the access those places already have. Treat the link like any other internal link and share it only in places your people already sign in to.

Internal status page cost, worked out for a real company

Most internal status page tools charge per page plan and cap how many people can read the private page. That cap is what drives the bill once the whole company reads it. Atlassian Statuspage prices below are from its public pricing page, checked in October 2026, with PagerDuty Professional at 21 USD a user a month billed annually for paging. IncidentBot prices are billed annually.

Plan	Private page price	Who can read it	Paging included
Atlassian Statuspage private Starter	79 USD a month	50 authenticated subscribers, 5 team members	No
Atlassian Statuspage private Growth	249 USD a month	300 authenticated subscribers, 15 team members	No
Atlassian Statuspage private Corporate	599 USD a month	1,000 authenticated subscribers, 35 team members	No
Atlassian Statuspage audience-specific	from 300 USD a month	from 500 users	No
IncidentBot Team	49 USD per responder seat a month, 3 public or private pages	Anyone with the private link, no reader cap	Yes, schedules, escalation, SMS, voice, push and email
IncidentBot Business	99 USD per responder seat a month, unlimited and audience-specific pages	Anyone with each page's link, no reader cap	Yes

For a company with 10 on-call responders and 600 employees who read the internal page, the math looks like this:

Stack	Monthly cost
Statuspage private Corporate (599 USD) plus PagerDuty Professional (10 x 21 USD)	809 USD
IncidentBot Team (10 x 49 USD), paging, incidents and private page included	490 USD

Where Statuspage wins: if all you need is a small private page for under 50 readers and you already have a paging tool, the 79 USD Starter plan is cheaper than any seat-priced product, and Statuspage signs readers in with SSO and can show system metrics on the page. Where IncidentBot wins: the page is written from the incident by the people running it, readers are not counted, and the pager, the Slack incident channel and the postmortem are in the same price. Full Statuspage plan details are on our Atlassian Statuspage pricing breakdown.

See pricing

Internal status page examples by audience

Engineering lead and an IT manager reviewing a vendor contract next to a laptop

A useful internal page lists the systems people actually depend on, grouped the way they think about them. A few layouts that work:

Company-wide page: email and calendar, VPN, SSO, HR and payroll system, the CRM, file storage, office Wi-Fi. Owned by IT operations, read by everyone. Our IT operations use case shows how the service desk runs it.
Support and success page: the customer-facing product split by feature (login, checkout, API, notifications, reporting) with more detail than the public page, plus known workarounds agents can paste into a reply.
Engineering dependencies page: internal APIs, queues, the data pipeline and CI, so other teams know a slow build is a known issue before they open an incident of their own.
Key account page on Business: a page that shows only the services one enterprise customer uses, shared with their admins instead of the public page.

Writing updates people can act on

Each update should answer three things in the first sentence: what is affected, who feels it and when the next update comes. "Checkout is failing for about 20 percent of card payments. Support can offer invoice payment as a workaround. Next update at 3:30 p.m. ET." is better than "We are investigating elevated error rates." Keep internal hostnames and speculation in the incident channel. The page is for confirmed facts.

From signup to a live internal page in one afternoon

If you also need a page for customers, the status page app covers public pages, maintenance notices and custom domains, and both pages are updated from the same incident. B2B software companies can see the full setup and cost on the status page for SaaS page. Teams leaving Atlassian can compare plans on the Statuspage alternative page.

Create your account and add the services you want to show, internal systems included.
Connect one monitoring source and build an escalation policy, so an alert reaches a person.
Create a status page, set it to private and pick which services it shows.
Share the private link in your intranet or service desk portal and turn on email subscriptions.
Run a test incident from Slack and publish one update to see what employees will see.

What is the difference between a public and an internal status page?

A public status page is written for customers and shows customer-facing services with careful wording. An internal status page is private, written for employees, and can list internal systems such as VPN, SSO or the CRM with more detail and known workarounds. Many companies run both from the same incident.

Who should have access to an internal status page?

Everyone who gets asked about outages: support, customer success, the service desk, sales and leadership, and often the whole company. Responders publish to it, everyone else only reads. In IncidentBot readers do not need a seat, so you can share the private link company-wide without a bigger bill.

How do you make a status page private?

In IncidentBot you set the page's visibility to private. The page then opens only through its own link with a secret access key, returns not-found to everyone else and is excluded from search engines and the sitemap. You share the link through your intranet or service desk portal.

How much does a private status page cost?

Atlassian Statuspage private pages cost 79, 249, 599 or 1,499 USD a month depending on how many authenticated readers you need. In IncidentBot private pages are part of the Team plan at 49 USD per responder seat a month billed annually, with paging and incident response included and no cap on readers.

Can an internal status page update itself from monitoring alerts?

It should not publish raw alerts, because an alert is not a confirmed impact and often fires on things readers do not care about. In IncidentBot alerts page the on-call engineer and open an incident, and a person publishes the update. That keeps the page accurate and still fast.

Can employees subscribe to updates?

Yes. On Team and above readers can subscribe to a page by email with a confirmation step, and they get each published update and the resolution. They can unsubscribe from any email.

Can we try it before we roll it out?

Yes. The incident simulator runs a sample incident in your browser with an alert, escalation, a Slack channel and a status update ready to publish, so you can see the flow before you create an account.

Give your company one place to check what is down

Create your account, add your internal systems and publish the first private update from a real incident.