CheckStatus
Sign In

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
Email Subscribers Public notifications for customers
Email Team members Internal team alerts
Email Team members Pre-maintenance reminders
Email 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:

  1. Click Status Pages in the sidebar
  2. Click Edit on the status page
  3. In the Page Visibility section, find Enable team notifications
  4. Check the box to enable notifications
  5. 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:

  1. In the Team Notifications section, check Send team reminder
  2. Select the reminder timing: 1, 2, 4, 12, or 24 hours before
  3. 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:

  1. Click your avatar in the top right and select Edit profile
  2. In the Notification Preferences section, uncheck Receive maintenance reminders
  3. 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

  1. Click Status Pages in the sidebar
  2. Click Edit on the status page
  3. Scroll to the Webhook URL field
  4. Enter your webhook endpoint URL
  5. 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

  1. Verify "Notify subscribers" was checked when creating/updating
  2. Check that the subscriber is confirmed (not pending)
  3. Ask subscriber to check spam/junk folder
  4. Verify the incident is published (not a draft)

Webhook Not Working

  1. Verify the webhook URL is correct and accessible
  2. Check that your endpoint returns a 2xx status code
  3. Verify the endpoint can receive POST requests
  4. Check your server logs for errors
  5. Ensure your endpoint responds within 30 seconds

Team Members Not Receiving Notifications

  1. Verify "Enable team notifications" is checked on the status page
  2. Check that team members have valid email addresses
  3. 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:

  1. Verify you're an account administrator (not just a team member)
  2. Check that the incident/maintenance has been active for at least 24 hours
  3. Check if you've already received 7 reminders (maximum limit)
  4. 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:

  1. Verify Send team reminder was checked when scheduling the maintenance
  2. 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)
  3. Verify the team member hasn't opted out in their profile settings (Edit profileNotification Preferences)
  4. Check that the maintenance hasn't been cancelled or started early (which cancels the reminder)
  5. 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