Skip to main content

​
Overview

The create_status_page_post tool creates a new post (incident or maintenance) on a status page. According to the PagerDuty API, all posts require starts_at, ends_at, and at least one update.
This is a write tool that creates a public-facing status page post. You must enable write tools with the --enable-write-tools flag to use this tool.

​
Parameters

​
status_page_id
string
required
The unique identifier of the status page on which to create the post.Example: "PSTATUS1"
​
title
string
required
The title of the post. This will be prominently displayed to status page viewers.Example: "API Latency Issues"
​
post_type
string
required
The type of post. Options:
  • incident - An unplanned service disruption
  • maintenance - A planned maintenance window
Example: "incident"
​
starts_at
datetime
required
The date and time when the post becomes effective. Required for both incident and maintenance posts.Example: "2024-01-15T14:00:00Z"
​
ends_at
datetime
required
The date and time when the post is concluded. Required for both incident and maintenance posts.Example: "2024-01-15T16:00:00Z"
​
status_page
object
required
Reference to the status page (duplicate of status_page_id for API compatibility).Example: {"id": "PSTATUS1", "type": "status_page"}
​
updates
array
required
List of post updates. At least one update is required when creating a post.

​
Response

Returns the created status page post object.
​
id
string
The unique identifier of the created post
​
type
string
Always returns "status_page_post"
​
post_type
string
The type of post (incident or maintenance)
​
title
string
The title of the post
​
status_page
object
Reference to the status page
​
starts_at
datetime
When the post becomes effective
​
ends_at
datetime
When the post is concluded
​
updates
array
List of post updates

​
Example Usage

"Create an incident post on status page PSTATUS1 for API latency issues"

​
Use Cases

  • Communicate incidents - Inform customers about service disruptions
  • Announce maintenance - Notify users of planned maintenance windows
  • Transparency - Keep stakeholders informed of service status
  • Reduce support load - Proactively communicate known issues
  • Meet SLAs - Fulfill communication requirements during incidents

​
Complete Example

{
  "status_page_id": "PSTATUS1",
  "title": "API Performance Degradation",
  "post_type": "incident",
  "starts_at": "2024-01-15T14:00:00Z",
  "ends_at": "2024-01-15T16:30:00Z",
  "status_page": {
    "id": "PSTATUS1",
    "type": "status_page"
  },
  "updates": [
    {
      "message": "We are investigating reports of increased API latency.",
      "status": {
        "id": "investigating",
        "type": "status_page_status"
      },
      "severity": {
        "id": "major",
        "type": "status_page_severity"
      },
      "impacted_services": [
        {
          "service": {"id": "SPSVC1", "type": "status_page_service"},
          "impact": {"id": "degraded_performance", "type": "status_page_impact"}
        }
      ],
      "notify_subscribers": true,
      "reported_at": "2024-01-15T14:00:00Z"
    }
  ]
}

​
Important Notes

  • Posts are immediately visible to status page viewers
  • Both starts_at and ends_at are required for all post types
  • At least one update is required when creating a post
  • Status and severity IDs must exist on your status page (use list tools to discover available options)
  • Setting notify_subscribers: true will send notifications to all subscribers
Before creating a post, you may want to:
  1. Use List Status Pages to get the status page ID
  2. Use list severities, statuses, and impacts tools to discover available options
  3. Verify the time zone and formatting of your timestamps

Build docs developers (and LLMs) love

Get started for freeTalk to us