Cross-system parallel of PUT /systems/{id}/alerts/silences/{silence_id}.
Preserves the original matchers and start time; only end_at and
comment change. Refuses to operate on silences without a
system_key matcher (404). Requires manage:systems permission.
PUT
/alerts/silences/{silence_id}
curl \
--request PUT 'https://api.your-domain.com/api/alerts/silences/d9f91c6e-1b33-484e-befa-bfb41020e178?organization_id=m4m3mdjdiizs' \
--header "Authorization: Bearer $ACCESS_TOKEN" \
--header "Content-Type: application/json" \
--data '{"comment":"extended for maintenance window","end_at":"2026-05-12T12:16:36Z"}'
Request example
Alertmanager treats an update as "create a new silence with
the same matchers and start_at, then drop the old one", so
the response carries a new `silence_id`. The activity
timeline records this as a `silence_updated` event.
{
"comment": "extended for maintenance window",
"end_at": "2026-05-12T12:16:36Z"
}
Response examples (200)
The `silence_id` differs from the one passed in the path:
Alertmanager replaced the silence under the hood while
preserving its matchers and start time.
{
"code": 200,
"message": "silence updated successfully",
"data": {
"silence_id": "f1e1c2a4-7e57-4b1a-aaa0-2b96c8b5a3aa"
}
}
Response examples (400)
{
"code": 400,
"message": "validation failed",
"data": {
"type": "validation_error",
"errors": [
{
"key": "username",
"message": "required",
"value": "string"
}
]
}
}
Response examples (401)
{
"code": 401,
"message": "invalid token",
"data": {}
}
Response examples (403)
{
"code": 403,
"message": "insufficient permissions",
"data": {}
}
Response examples (404)
{
"code": 400,
"message": "validation failed",
"data": {
"type": "validation_error",
"errors": [
{
"key": "username",
"message": "required",
"value": "string"
}
]
}
}