Account & Settings
Notifications
Learn how to configure email and webhook notifications
Keep your customers and team informed with CheckStatus notifications. This guide covers how to configure email notifications for subscribers, team notifications, and webhook integrations.
Notification Types
CheckStatus can send notifications through multiple channels:
| Channel | Recipients | Use Case |
|---|---|---|
| Subscribers | Public notifications for customers | |
| Team members | Internal team alerts | |
| Team members | Pre-maintenance reminders | |
| Account admins | Long-running incident/maintenance reminders | |
| Webhooks | External systems | Integrations with other tools |
Email Notifications for Subscribers
Subscribers who sign up on your status page receive email notifications when incidents and maintenance events occur.
When Subscribers Receive Notifications
Subscribers are notified based on the Notify subscribers checkbox when you create or update incidents and maintenance:
| Event | How to Trigger Notification |
|---|---|
| Incident created | Check "Notify subscribers" when creating an incident |
| Incident updated | Check "Notify subscribers" when posting an update |
| Incident resolved | Check "Notify subscribers" when resolving |
| Maintenance scheduled | Check "Notify subscribers" when scheduling |
| Maintenance started | Automatic if maintenance auto-starts, or check when manually starting |
| Maintenance updated | Check "Notify subscribers" when posting an update |
| Maintenance completed | Automatic if maintenance auto-completes, or check when manually completing |
Note: Draft incidents don't trigger notifications. Only published incidents send emails.
Notification Email Content
Subscriber emails include:
- Your logo and branding
- Incident or maintenance title
- Current status
- Update message
- Link to view full details on your status page
- Unsubscribe link
Team Notifications
Team members can receive internal notifications about activity on your status pages.
Enabling Team Notifications
Team notifications are configured per status page:
- Click Status Pages in the sidebar
- Click Edit on the status page
- In the Page Visibility section, find Enable team notifications
- Check the box to enable notifications
- Click Save Changes
When enabled, all team members will receive email and webhook alerts when incidents are created or updated on that status page.
Team Notification Events
When team notifications are enabled, team members are notified about:
- New incidents created
- Incident status changes and updates
- New scheduled maintenance
- Maintenance status changes and updates
Long-Running Reminders
CheckStatus automatically sends reminder emails to account admins when incidents or maintenance remain active for extended periods. This helps ensure that long-running issues don't get forgotten.
How Reminders Work
| Timing | Description |
|---|---|
| First reminder | 24 hours after incident/maintenance becomes active |
| Subsequent reminders | Every 24 hours thereafter |
| Maximum reminders | 7 reminders total (stops after 7 days) |
Who Receives Reminders
Reminders are sent to account administrators only, not all team members. This ensures the right people are notified without creating notification overload for the entire team.
Reminder Email Content
Each reminder email includes:
- Warning banner showing how many days the incident/maintenance has been active
- Event details (title, status, start time, duration)
- Affected components
- Reminder count (e.g., "Reminder 3 of 7")
- Quick action buttons to resolve the incident or complete the maintenance
What Triggers Reminders
| Event Type | When Reminders Start |
|---|---|
| Incidents | When incident has been active (investigating, identified, or monitoring) for 24+ hours |
| Maintenance | When maintenance has been in progress for 24+ hours |
Stopping Reminders
Reminders stop automatically when:
- The incident is resolved
- The maintenance is completed or cancelled
- 7 reminders have been sent (after 7 days)
Tip: If you receive a reminder for an incident that's no longer relevant, simply resolve it in CheckStatus to stop future reminders.
Pre-Maintenance Team Reminders
Get your team prepared for upcoming maintenance with automatic reminder emails sent before maintenance begins.
Enabling Team Reminders
When scheduling maintenance, you can enable team reminders:
- In the Team Notifications section, check Send team reminder
- Select the reminder timing: 1, 2, 4, 12, or 24 hours before
- Your preferences are saved as defaults for future maintenances
Who Receives Pre-Maintenance Reminders
All team members in your account receive the reminder email, unless they have opted out (see below).
Reminder Email Content
Pre-maintenance reminder emails include:
- Maintenance title and description
- Scheduled start and end times
- Expected duration
- Affected components
- Link to view maintenance details
When Reminders Are Cancelled
Team reminders are automatically cancelled when:
- The maintenance is cancelled
- The maintenance is started manually (before the scheduled time)
- The reminder time has already passed when scheduling
Opting Out of Team Reminders
Individual team members can opt out of receiving pre-maintenance reminders:
- Click your avatar in the top right and select Edit profile
- In the Notification Preferences section, uncheck Receive maintenance reminders
- Click Update
This only affects pre-maintenance reminder emails. Other notifications (incident alerts, team notifications, long-running reminders) are not affected by this setting.
Learn more about team reminders →
Webhook Notifications
Webhooks allow you to integrate CheckStatus with external systems like Slack, PagerDuty, or your own applications.
Setting Up a Webhook
- Click Status Pages in the sidebar
- Click Edit on the status page
- Scroll to the Webhook URL field
- Enter your webhook endpoint URL
- Click Save Changes
Webhook Events Summary
| Event | Trigger |
|---|---|
incident.created |
Incident published (draft → investigating/identified/monitoring) |
incident.updated |
Incident state changed (e.g., investigating → identified) |
incident.resolved |
Incident marked as resolved |
incident_update.created |
New update posted with webhook checkbox enabled |
maintenance.scheduled |
New maintenance window created |
maintenance.started |
Maintenance begins (scheduled → in_progress) |
maintenance.completed |
Maintenance finishes successfully |
maintenance.cancelled |
Maintenance cancelled |
Webhook Payloads
When an event occurs, CheckStatus sends a POST request to your webhook URL with event data in JSON format.
incident.created
Sent when a new incident is published (transitions from draft to active state).
{
"event": "incident.created",
"timestamp": "2025-12-04T10:30:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"incident": {
"id": "inc_xyz789ghi012",
"title": "API Server Outage",
"state": "investigating",
"impact": "major",
"url": "https://status.example.com/incidents/inc_xyz789ghi012",
"started_at": "2025-12-04T10:30:00Z",
"resolved_at": null,
"created_at": "2025-12-04T10:28:00Z",
"updated_at": "2025-12-04T10:30:00Z",
"affected_components": [
{
"id": "comp_abc123",
"name": "API Server",
"status": "major_outage",
"description": "Main REST API endpoints"
},
{
"id": "comp_def456",
"name": "Authentication",
"status": "partial_outage",
"description": "User authentication services"
}
]
}
}
incident.updated
Sent when an incident's state changes (e.g., investigating → identified → monitoring).
{
"event": "incident.updated",
"timestamp": "2025-12-04T11:15:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"incident": {
"id": "inc_xyz789ghi012",
"title": "API Server Outage",
"state": "identified",
"previous_state": "investigating",
"impact": "major",
"url": "https://status.example.com/incidents/inc_xyz789ghi012",
"started_at": "2025-12-04T10:30:00Z",
"resolved_at": null,
"created_at": "2025-12-04T10:28:00Z",
"updated_at": "2025-12-04T11:15:00Z",
"affected_components": [
{
"id": "comp_abc123",
"name": "API Server",
"status": "major_outage",
"description": "Main REST API endpoints"
}
]
}
}
incident.resolved
Sent when an incident is marked as resolved.
{
"event": "incident.resolved",
"timestamp": "2025-12-04T12:45:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"incident": {
"id": "inc_xyz789ghi012",
"title": "API Server Outage",
"state": "resolved",
"previous_state": "monitoring",
"impact": "major",
"url": "https://status.example.com/incidents/inc_xyz789ghi012",
"started_at": "2025-12-04T10:30:00Z",
"resolved_at": "2025-12-04T12:45:00Z",
"created_at": "2025-12-04T10:28:00Z",
"updated_at": "2025-12-04T12:45:00Z",
"affected_components": [
{
"id": "comp_abc123",
"name": "API Server",
"status": "operational",
"description": "Main REST API endpoints"
}
]
}
}
incident_update.created
Sent when a new update is posted to an incident (when "Send webhook notification" is checked).
{
"event": "incident_update.created",
"timestamp": "2025-12-04T11:00:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"incident": {
"id": "inc_xyz789ghi012",
"title": "API Server Outage",
"state": "identified",
"impact": "major",
"url": "https://status.example.com/incidents/inc_xyz789ghi012",
"started_at": "2025-12-04T10:30:00Z",
"resolved_at": null,
"created_at": "2025-12-04T10:28:00Z",
"updated_at": "2025-12-04T11:00:00Z",
"affected_components": [
{
"id": "comp_abc123",
"name": "API Server",
"status": "major_outage",
"description": "Main REST API endpoints"
}
]
},
"incident_update": {
"id": 42,
"message": "We have identified the root cause as a database connection pool exhaustion. Our team is working on increasing pool capacity and implementing a fix.",
"state": "identified",
"created_at": "2025-12-04T11:00:00Z",
"updated_at": "2025-12-04T11:00:00Z"
}
}
maintenance.scheduled
Sent when a new maintenance window is created.
{
"event": "maintenance.scheduled",
"timestamp": "2025-12-04T09:00:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"maintenance": {
"id": "maint_jkl345mno678",
"title": "Database Upgrade - PostgreSQL 16",
"state": "scheduled",
"url": "https://status.example.com/maintenances/maint_jkl345mno678",
"scheduled_start_at": "2025-12-07T02:00:00Z",
"scheduled_end_at": "2025-12-07T04:00:00Z",
"actual_start_at": null,
"actual_end_at": null,
"created_at": "2025-12-04T09:00:00Z",
"updated_at": "2025-12-04T09:00:00Z",
"affected_components": [
{
"id": "comp_ghi789",
"name": "Database",
"status": "operational",
"description": "Primary PostgreSQL database cluster"
}
]
}
}
maintenance.started
Sent when a maintenance window begins.
{
"event": "maintenance.started",
"timestamp": "2025-12-07T02:00:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"maintenance": {
"id": "maint_jkl345mno678",
"title": "Database Upgrade - PostgreSQL 16",
"state": "in_progress",
"previous_state": "scheduled",
"url": "https://status.example.com/maintenances/maint_jkl345mno678",
"scheduled_start_at": "2025-12-07T02:00:00Z",
"scheduled_end_at": "2025-12-07T04:00:00Z",
"actual_start_at": "2025-12-07T02:00:00Z",
"actual_end_at": null,
"created_at": "2025-12-04T09:00:00Z",
"updated_at": "2025-12-07T02:00:00Z",
"affected_components": [
{
"id": "comp_ghi789",
"name": "Database",
"status": "under_maintenance",
"description": "Primary PostgreSQL database cluster"
}
]
}
}
maintenance.completed
Sent when a maintenance window finishes successfully.
{
"event": "maintenance.completed",
"timestamp": "2025-12-07T03:45:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"maintenance": {
"id": "maint_jkl345mno678",
"title": "Database Upgrade - PostgreSQL 16",
"state": "completed",
"previous_state": "in_progress",
"url": "https://status.example.com/maintenances/maint_jkl345mno678",
"scheduled_start_at": "2025-12-07T02:00:00Z",
"scheduled_end_at": "2025-12-07T04:00:00Z",
"actual_start_at": "2025-12-07T02:00:00Z",
"actual_end_at": "2025-12-07T03:45:00Z",
"created_at": "2025-12-04T09:00:00Z",
"updated_at": "2025-12-07T03:45:00Z",
"affected_components": [
{
"id": "comp_ghi789",
"name": "Database",
"status": "operational",
"description": "Primary PostgreSQL database cluster"
}
]
}
}
maintenance.cancelled
Sent when a maintenance window is cancelled.
{
"event": "maintenance.cancelled",
"timestamp": "2025-12-06T15:00:00Z",
"status_page": {
"id": "sp_abc123def456",
"name": "Production Status",
"subdomain": "status",
"url": "https://status.example.com"
},
"maintenance": {
"id": "maint_jkl345mno678",
"title": "Database Upgrade - PostgreSQL 16",
"state": "cancelled",
"previous_state": "scheduled",
"url": "https://status.example.com/maintenances/maint_jkl345mno678",
"scheduled_start_at": "2025-12-07T02:00:00Z",
"scheduled_end_at": "2025-12-07T04:00:00Z",
"actual_start_at": null,
"actual_end_at": "2025-12-06T15:00:00Z",
"created_at": "2025-12-04T09:00:00Z",
"updated_at": "2025-12-06T15:00:00Z",
"affected_components": [
{
"id": "comp_ghi789",
"name": "Database",
"status": "operational",
"description": "Primary PostgreSQL database cluster"
}
]
}
}
Webhook Security
Webhooks include a signature header for verification:
- Header:
X-CheckStatus-Signature - Algorithm: HMAC-SHA256
Use the signature to verify that webhook requests are genuinely from CheckStatus.
Controlling Notifications When Creating Content
When Creating an Incident
On the Create Incident form, you'll find:
- Notify subscribers checkbox (checked by default)
- Uncheck to create an incident without notifying subscribers
When Posting an Incident Update
On the Edit Incident page, the Post Update section includes:
- Notify subscribers checkbox
- Check to send notifications with this update
When Scheduling Maintenance
On the Schedule Maintenance form, you'll find:
- Notify subscribers checkbox (checked by default)
- Uncheck to schedule maintenance silently
Managing Notification Overload
For Subscribers
- Don't post too many updates for minor changes
- Combine related updates when possible
- Use clear, concise messages
- Always send resolution notifications
For Your Team
- Enable team notifications only for status pages that need monitoring
- Use webhooks to route notifications to specific team channels (e.g., Slack)
- Consider the volume of notifications before enabling
Troubleshooting
Subscribers Not Receiving Emails
- Verify "Notify subscribers" was checked when creating/updating
- Check that the subscriber is confirmed (not pending)
- Ask subscriber to check spam/junk folder
- Verify the incident is published (not a draft)
Webhook Not Working
- Verify the webhook URL is correct and accessible
- Check that your endpoint returns a 2xx status code
- Verify the endpoint can receive POST requests
- Check your server logs for errors
- Ensure your endpoint responds within 30 seconds
Team Members Not Receiving Notifications
- Verify "Enable team notifications" is checked on the status page
- Check that team members have valid email addresses
- Ask team members to check spam/junk folders
Delayed Notifications
Notifications are typically sent within seconds, but may be delayed during:
- High volume periods
- Scheduled maintenance on our end
- Email provider delays
If delays persist, contact support.
Long-Running Reminders Not Being Sent
Long-running reminders are sent once daily (at 7:00 AM UTC for incidents, 7:05 AM UTC for maintenance). If you're not receiving reminders:
- Verify you're an account administrator (not just a team member)
- Check that the incident/maintenance has been active for at least 24 hours
- Check if you've already received 7 reminders (maximum limit)
- Verify the incident is in an active state (not resolved/draft) or maintenance is in progress (not completed/cancelled)
Pre-Maintenance Team Reminders Not Being Sent
If team members are not receiving pre-maintenance reminders:
- Verify Send team reminder was checked when scheduling the maintenance
- Check that the reminder timing is less than the time until maintenance starts (e.g., a 24-hour reminder won't be sent if maintenance is only 12 hours away)
- Verify the team member hasn't opted out in their profile settings (Edit profile → Notification Preferences)
- Check that the maintenance hasn't been cancelled or started early (which cancels the reminder)
- Ask the team member to check spam/junk folders
Best Practices
Subscriber Communication
- Write clear, jargon-free update messages
- Include estimated resolution times when known
- Post regular updates during long incidents
- Always acknowledge when issues are resolved
Webhook Integration
- Implement signature verification for security
- Handle webhook failures gracefully
- Log incoming webhooks for debugging
- Set up retry logic on your end if needed
Notification Frequency
- Aim for meaningful updates, not frequent ones
- Group related changes when possible
- Notify immediately for critical incidents
- Consider time zones for maintenance notifications
Related Topics
- Incidents - Create incidents that trigger notifications
- Scheduled Maintenance - Schedule maintenance
- Subscribers - Manage email subscribers
- Team Management - Manage team access