Atlassian Statuspage is the incident communication layer for most enterprise SaaS operations. When an incident occurs, the response team posts updates to Statuspage — incident created, update posted, incident resolved. Subscribers (email, SMS, webhook, RSS) receive those updates in real time.
Statuspage webhook subscribers receive HTTP POST payloads when incident events fire. A Slack incoming webhook URL configured as a Statuspage subscriber receives incident notifications in a Slack channel automatically.
Statuspage has no native Teams integration. There is no Microsoft Teams connector in Statuspage subscriber settings. There is no built-in Teams webhook destination. Teams-side stakeholders — engineering leadership, customer success teams, executive sponsors — are not Statuspage subscribers unless someone configures an email subscription or manually posts updates to Teams channels.
Who Misses the Notification
In most enterprise organizations, the operational split looks like this:
SRE and on-call engineers use Slack. They are in Slack channels monitoring PagerDuty alerts and Datadog graphs. They see the Statuspage incident notification in their Slack monitoring channel the moment it fires.
Engineering leadership and executives use Teams. Microsoft 365 is the enterprise standard for management layers. When a major incident fires, these stakeholders track progress through Teams — but Statuspage notifications don't reach Teams channels automatically. They rely on someone from the response team to post a manual update.
Customer success and support teams may use either platform depending on organization. For CS teams on Teams, Statuspage component degradation events — especially for production components affecting customers — need real-time notification. Instead they check the status page manually or wait for Slack-side colleagues to post updates.
Closing the Loop: Incident Opened → Resolved
The most important property of incident notification routing is closing the loop. When an incident is resolved, the same channels that received the incident.create notification should receive the incident.resolve notification. With a single Statuspage webhook pointing to SyncRivo, this happens automatically:
- incident.create fires → SyncRivo routes to Slack #on-call + Teams Engineering Leads simultaneously
- incident.update fires (new update posted) → same channels receive the update
- incident.resolve fires → same channels receive resolution confirmation
No manual follow-up posts to Teams. No leadership left wondering whether the incident is resolved hours later.
PagerDuty + Statuspage: Combined Incident Workflow
Most incident management stacks pair PagerDuty with Statuspage. PagerDuty handles alerting and on-call routing; Statuspage handles public and internal status communication. PagerDuty can update Statuspage automatically via the PagerDuty Statuspage extension.
With SyncRivo, configure both tools to route to messaging platforms:
- PagerDuty webhook → SyncRivo → Slack #on-call (high-urgency alert routing, immediate response)
- Statuspage webhook → SyncRivo → Slack #operations + Teams Engineering Leads + Teams Customer Success (lifecycle communication, broader stakeholder audience)
The response team gets PagerDuty alerts in Slack for immediate action. Leadership and customer success get Statuspage lifecycle updates in Teams as the incident progresses. Both flows are automatic, from the same incident, with no manual posting to Teams.
For the complete Statuspage webhook subscriber setup, component status routing, and PagerDuty combined workflow, see the Statuspage Incident Notifications in Slack & Teams integration guide.
Ready to connect your messaging platforms?
