---
title: "Send a synchronous test alert to a recipient (issue"
method: POST
path: "/api/v1/recipients/{recipientID}/test"
---

# Send a synchronous test alert to a recipient (issue

`POST /api/v1/recipients/{recipientID}/test`

## Request

- Base URL: `https://api.uptimemonitoring.com`
- URL: `https://api.uptimemonitoring.com/api/v1/recipients/{recipientID}/test`
- Auth: HTTP bearer

Dispatches a `[TEST]` alert (email), a signed
`event: "monitor.test"` POST (webhook), an unsigned 🧪 TEST
Block Kit message (slack, issue #359), or a PagerDuty Events API v2
trigger-then-resolve pair (pagerduty, issue #363) directly —
bypasses the `webhook_deliveries` outbox entirely, since there is
no real monitor behind a test send. Rate-limited to 1 per
recipient per minute. A `pending` or `disabled` recipient returns
409. For `type=slack`, a non-2xx response — 3xx included — is
reported as `status="failed"` with `response_code` and `error` set
to Slack's own response body (e.g. `"no_service"`); only a
transport failure returns the top-level 502. For `type=pagerduty`,
the trigger (severity `info`) is followed by an immediate resolve
under the identical `dedup_key`, ONLY if the trigger's response was
2xx; a successful pair reports `status="accepted"` (never
`"delivered"`, since PagerDuty's Events API is asynchronous and two
2xx responses do not prove the test incident actually closed) with
`message` carrying that caveat. Any failure — a non-2xx trigger, a
transport error on either request, or a non-2xx resolve — reports
`status="failed"`; every failure except a cleanly-rejected trigger
also carries a warning in `error` that a test incident may remain
open in PagerDuty. No PagerDuty response body is ever read or
returned; `error`/`message` always come from fixed outcome text.

## Response `200`

Test attempted (check `status` for the outcome)

- RecipientTestResult: Response body of `POST /api/v1/recipients/{recipientID}/test`.
  - `recipient_id` integer
  - `type` 'webhook' | 'email' | 'slack' | 'pagerduty'
  - `status` 'delivered' | 'accepted' | 'failed': `accepted` is PagerDuty-only: PagerDuty's Events API v2 is asynchronous, so a 2xx response to the test trigger and its immediate resolve does not prove the test incident actually closed — see `message`.
  - `response_code` integer: Webhook: the destination's HTTP status. Email: 202 on success, SendGrid's status on failure, or 0 for a transport error. Slack: Slack's HTTP status, 3xx included (a redirect is never followed and is reported as its own 3xx code) — only a transport failure omits this field (502). PagerDuty: the trigger's HTTP status on success or on a trigger rejection; the resolve's HTTP status when the trigger succeeded but the resolve failed; omitted for a transport error on either request. Omitted when no response was obtained at all (502).
  - `error` string: Present only when status is "failed" or the request 502s. For `type=pagerduty`, this is always fixed outcome text (e.g. `"PagerDuty rejected the event (HTTP 400)"`) — never a response body, which could echo the routing key — and, for every failure except a cleanly-rejected trigger, is followed by a warning that a test incident may remain open in PagerDuty.
  - `message` string: Present only for `type=pagerduty` on a successful `status="accepted"` test send: notes that PagerDuty processes events asynchronously and a test incident can remain open, to be resolved in PagerDuty if so. Omitted for every other type and outcome.

## Other responses

- `404`: Recipient not found
- `409`: Recipient not active (pending or disabled)
- `429`: Per-account dispatcher rate limit exceeded (200 requests/minute). The `Retry-After` header gives the integer seconds until at least one token has refilled. The `X-RateLimit-*` trio reflects the bucket whose rejection produced this response — usually the global 200/min cap; on `POST /api/v1/monitors` a 429 may instead reflect the per-route 20/min creation limit.
- `502`: No response could be obtained from the destination

---

[API](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api.md) · [All operations](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/llms.txt) · [OpenAPI document](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/revisions/ddcb2a8bc70f?raw)