Pingtower
Docs
Actions
A runbook action is an HTTP call the service makes for you when an alert opens. Restart the worker, open the ticket, flip the feature flag, before anyone wakes up.
{
"name": "restart-gateway-worker",
"method": "POST",
"url": "https://deploy.acme.example/api/services/gateway-worker/restart",
"headers": { "Authorization": "Bearer …" },
"body": "{\"reason\":\"pingtower\"}",
"timeout_seconds": 10,
"events": ["alert.opened"],
"enabled": true
}
| Field | Meaning |
|---|---|
name | Identity. Rules reference it by name or id. |
method | GET, POST, PUT, PATCH or DELETE. |
url | http or https, up to 2048 characters. Private and loopback ranges are refused. |
headers | Up to 32. Sealed at rest; reads return only header_keys. |
body | Up to 8 KiB. Sealed at rest; reads return has_body. Send "" to clear it, omit it to keep it. |
timeout_seconds | 0 to 60, default 10. |
events | alert.opened, alert.escalated, or both. Default alert.opened. |
enabled | A disabled action is skipped silently. |
Stored headers and body are tied to the exact url and method they were set with. An update that changes either, even only the path or a query parameter, must send headers and body again ({} and "" to drop them), or it is refused with a 400 whose fields entry for headers or body has the rule required_on_redirect and says headers must be re-supplied when the url or method changes; the stored value is sealed and is not sent to a new destination. A missing method counts as GET. Nothing is dropped silently. Other edits keep them. A channel, webhook or action saved before Pingtower recorded who last pointed it at its destination reads back with "pointer_review": true, and the web app shows it with a review pill. Check the destination is yours. The flag clears when a member whose role holds members:write (an owner, an admin, or a custom manager role) saves it, when its destination changes, or when it is re-enabled.
POST GET /v1/projects/{id}/actions, then GET PUT DELETE /v1/projects/{id}/actions/{aid}.
Wiring it to a rule
A rule’s actions list names the actions to run. They fire when the alert opens, and again on each escalation for actions whose events include alert.escalated. The reference is checked when the rule is saved, and an action a rule still names cannot be deleted or renamed: 409 with the list of rules.
Test and history
POST /v1/projects/{id}/actions/{aid}/test fires it once, synchronously, with a synthetic alert, and records the result.
GET /v1/projects/{id}/actions/{aid}/executions?limit= lists runs, newest first: alert_id, event, status, status_code, the first bytes of the response as response_prefix, error, attempts, duration_ms, executed_at, and trigger, which says how the run started: alert when a rule fired it, manual when someone ran it by hand, test for a test fire. A manual run also carries run_by, the account that ran it. The app shows this under the action. Deleting an action keeps its execution rows.
Running it by hand
From an alert in the iOS app, Run action… picks one of the project’s actions and fires it at once. It is for the alert in front of you: an action no rule wires up, or one you want to run again.
- It sends the same request an automatic firing would. An action’s request is fixed, so nothing from the alert is put into it.
- It is synchronous: the answer says whether the call succeeded and the status code it got back, or the error. It is tried once, with no retry.
- It is never deduplicated against an automatic run. Pressing the button means it.
- The action must be enabled, and the alert must belong to the same project. The alert can be open or resolved.
- It is recorded in the execution log against that alert, with
eventalert.manual,triggermanualandrun_bynaming who ran it, and written to the audit log.
Members and up can run an action, or any custom role with actions:write. Responders and viewers cannot.