Skip to main content

​
Overview

The create_status_page_post_update tool adds a new update to an existing status page post. Use this to provide progress updates during an incident or maintenance window.
This is a write tool that creates a public-facing status update. 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.Example: "PSTATUS1"
​
post_id
string
required
The unique identifier of the status page post to update.Example: "POST123"
​
message
string
required
The message text for the update. This is what status page viewers will see.Example: "The issue has been identified and a fix is being deployed"
​
status
object
required
Status reference indicating the current state of the incident or maintenance.Common status IDs for incidents:
  • investigating - Initial response, investigating the issue
  • identified - Root cause has been identified
  • monitoring - Fix deployed, monitoring for stability
  • resolved - Issue completely resolved
Common status IDs for maintenance:
  • scheduled - Maintenance is scheduled
  • in_progress - Maintenance is currently underway
  • completed - Maintenance has been completed
Example: {"id": "identified", "type": "status_page_status"}
​
severity
object
required
Severity reference indicating the impact level.Common severity IDs:
  • none - No impact
  • minor - Minor impact
  • major - Major impact
  • critical - Critical impact
Example: {"id": "major", "type": "status_page_severity"}
​
post
object
Post reference (required by API).Example: {"id": "POST123", "type": "status_page_post"}
​
impacted_services
array
default:"[]"
List of impacted services with their impact levels. Can be an empty array if no services are impacted or if impact hasn’t changed.Example:
[
  {
    "service": {"id": "SPSVC1", "type": "status_page_service"},
    "impact": {"id": "partial_outage", "type": "status_page_impact"}
  }
]
​
notify_subscribers
boolean
default:"false"
Whether to notify subscribers of this update. Set to true for important updates.Example: true
​
update_frequency_ms
integer
The frequency of the next update in milliseconds. Use null for no scheduled frequency.Example: 1800000 (30 minutes)
​
reported_at
datetime
The date and time when the update was reported. Defaults to now if not specified.Example: "2024-01-15T14:30:00Z"

​
Response

Returns the created post update object.
​
id
string
The unique identifier of the created post update
​
type
string
Always returns "status_page_post_update"
​
message
string
The message text of the update
​
status
object
The status reference
​
severity
object
The severity reference
​
post
object
Reference to the parent post
​
impacted_services
array
List of impacted services
​
notify_subscribers
boolean
Whether subscribers were notified
​
reported_at
datetime
When the update was reported

​
Example Usage

"Update status page post POST123 - issue has been identified"

​
Use Cases

  • Progress updates - Keep customers informed during incident resolution
  • Status changes - Communicate when moving from investigating to identified to resolved
  • Transparency - Provide regular updates even if there’s no significant progress
  • Resolution confirmation - Confirm when issues are fully resolved
  • Maintenance progress - Update on maintenance completion status

​
Complete Example

{
  "status_page_id": "PSTATUS1",
  "post_id": "POST123",
  "message": "The issue has been identified. Our team is deploying a fix and we expect resolution within 30 minutes.",
  "status": {
    "id": "identified",
    "type": "status_page_status"
  },
  "severity": {
    "id": "major",
    "type": "status_page_severity"
  },
  "post": {
    "id": "POST123",
    "type": "status_page_post"
  },
  "impacted_services": [
    {
      "service": {"id": "SPSVC1", "type": "status_page_service"},
      "impact": {"id": "degraded_performance", "type": "status_page_impact"}
    }
  ],
  "notify_subscribers": true,
  "update_frequency_ms": 1800000,
  "reported_at": "2024-01-15T14:30:00Z"
}

​
Update Workflow Example

# 1. Initial update - investigating
"Create update for post POST123: We are investigating increased API latency"

# 2. Progress update - identified
"Update post POST123: Issue identified, deploying fix"

# 3. Monitoring update
"Update post POST123: Fix deployed, monitoring for stability"

# 4. Resolution
"Update post POST123 as resolved: All systems operating normally"

​
Important Notes

  • Updates are immediately visible to all status page viewers
  • Setting notify_subscribers: true sends notifications to all subscribers
  • Status and severity changes should reflect the actual state of the incident
  • Provide meaningful updates - avoid generic messages
  • Consider your update frequency based on incident severity
Best Practices:
  • Update regularly during active incidents (every 30-60 minutes)
  • Be specific about what actions are being taken
  • Use appropriate status transitions (investigating → identified → monitoring → resolved)
  • Notify subscribers for important status changes
  • Include estimated time to resolution when known

Build docs developers (and LLMs) love

Get started for freeTalk to us