# How to Send a monday.com Status Alert to Your Team's Phones

> Use monday.com's HTTP Request block to send one selected status change to a shared PingRoom Room, while monday.com remains the source of truth.

- Published: 2026-10-21
- Author: PingRoom
- Category: Developers
- Topics: monday.com push notification, monday status change alert, monday HTTP request webhook
- Canonical: https://pingroom.io/blog/monday-status-change-push-notifications
- Cover image: https://pingroom.io/blog/monday-status-change-push-notifications-cover.webp
- Cover description: Two PingRoom avatars move one plain clay task tile into a review tray while Pingo watches from the project table.

**To send one monday.com status change to a shared group of phones, build a monday workflow that triggers on a selected status and add a _Send HTTP Request_ block pointed at a PingRoom incoming webhook.** Keep the message fixed and short, test it with a harmless item, and leave the board record in monday.com.

This is a webhook recipe, not a native monday.com integration. It is useful when a small group needs one shared signal—**Ready for review**, for example—without asking everyone to follow every board item.

## Check monday.com's own notifications first

monday.com already provides bell, email, and mobile notifications for people who are assigned, mentioned, subscribed, or targeted by a notification automation. Its [notification guide](https://support.monday.com/hc/en-us/articles/360001292545-Notifications-explained) recommends focused notify actions for important status changes.

| Need                                                                      | Better starting point                                                       |
| ------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| People already work in monday.com and need normal item context            | monday.com's native notifications                                           |
| A small shared group needs one selected milestone on their phones         | monday workflow → PingRoom incoming webhook                                 |
| Recipients need the item name, owner, files, updates, or activity history | Open monday.com                                                             |
| The transition drives a regulated, safety-critical, or durable process    | Keep the established record and escalation path; use a reviewed integration |

A Ping is an attention cue. It is not the board record and does not prove that the work is correct, approved, or complete.

## Create one destination Room

Create a private PingRoom Room for the people who need the status signal. The Room owner needs **PingRoom Pro** for incoming webhooks.

Open the Room's **Settings → Connections → From another app**, add a webhook, leave **Quick Ping** on **Custom message**, and copy the complete webhook URL. A Room can have up to four incoming webhooks.

The URL contains the secret. Anyone who can read it can fire the Room. Treat permission to edit or inspect the monday workflow as credential access, and do not paste the URL into an item, update, screenshot, or public runbook. If it leaks, regenerate the secret in PingRoom and replace the URL in monday.com.

The broader [webhook setup guide](/blog/webhook-to-push-notification) explains the PingRoom response. The [incoming-webhook reference](/documents/webhooks) carries the current field limits, cooldown behavior, and errors.

## Build one selected-status workflow

Open monday.com's workflow builder and create a workflow from scratch. Add the board trigger for **When a status changes to something**, choose the board and status column, and set the destination value to one useful state such as **Ready for review**.

Do not start with “any status change.” A narrow destination prevents edits, reassignments, and intermediate states from turning into phone noise.

Add monday.com's documented [**Send HTTP Request** block](https://support.monday.com/hc/en-us/articles/33515393103378-HTTP-Request-block-in-the-AI-workflow-builder). Configure it as follows:

- Method: `POST`
- URL: the complete PingRoom webhook URL
- Headers: the two lines below, with no spaces around the colon
- Body type: `JSON`
- Body: the JSON below

Use these headers:

```text
Accept:application/json
Content-Type:application/json
```

Use this body:

```json
{
  "title": "Ready for review",
  "message": "One item is ready for review"
}
```

The fixed copy is deliberate. It avoids putting an item name, customer, owner, priority, link, or project detail on a lock screen. The selected trigger already decides which board moment deserves attention; authorized teammates can open monday.com for the record.

If a generic message is not enough, use the workflow builder's field picker to add only the minimum safe reference, such as the item ID from the trigger step. monday.com documents passing an item ID between blocks, but its current public HTTP-block guide does not document a universal text token for every trigger. Use the field picker shown in your account rather than copying an invented placeholder from a blog post.

![Two PingRoom avatars stand by a studio doorway after a project handoff while one checks a phone and Pingo waits beside a small signal lamp.](/blog/monday-status-change-push-notifications-1.webp)

_These AI-generated editorial illustrations feature approved PingRoom avatars and Pingo the Pigeon, PingRoom's fictional Chief Marketing Officer. They are not monday.com or PingRoom screenshots and do not depict customers._

[Pingo](/Pingo) is only observing the handoff in the illustration. He has no monday.com account, no private-Room access, and no authority to change the board or send a Ping. The human team chooses the trigger, message, recipients, and secret access.

## Do not use the ordinary Webhook integration directly

monday.com also has a separate board **Webhook integration**. Its [setup guide](https://support.monday.com/hc/en-us/articles/360003540679-Webhook-integration) says the receiving URL must answer a JSON challenge before monday.com accepts it.

A PingRoom incoming webhook accepts Ping fields; it is not a monday.com challenge endpoint. Pasting the PingRoom URL into that ordinary Webhook integration will therefore fail the verification step.

Use the direct **Send HTTP Request** block for the simple recipe above. Use a server-side relay only when you specifically need the ordinary Webhook integration's event payload. That relay must echo the challenge, verify and filter the event, transform its payload into PingRoom's contract, keep both secrets off the client, and handle retries. A possible relay is not a native integration.

## Understand the retry boundary

monday.com's HTTP-block documentation says transient server failures can trigger retries. PingRoom supports an `Idempotency-Key`, but a safe key must identify one source event consistently across retries.

The current public monday.com guides we inspected document the item ID between workflow blocks, but not a stable per-run or per-transition identifier for this HTTP request. This recipe therefore does **not** invent one. A retry after an uncertain response can create a duplicate Ping.

Choose the route based on that boundary:

| Requirement                                                                 | Route                                                                |
| --------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Occasional shared status signal; a rare duplicate is acceptable and visible | Direct HTTP Request block                                            |
| Exactly one alert per source event is operationally important               | Challenge-aware relay or reviewed integration with a stable event ID |
| Normal work-item notifications for monday.com users                         | Native monday.com notifications                                      |

If your account exposes a documented stable run or event value, you can map it to an `Idempotency-Key` header after testing repeated delivery with the same body. Do not use only the item ID plus status if an item can leave and later re-enter that status; that would collapse two real transitions into one identity.

## Test the whole path with harmless work

Before publishing the workflow:

1. Create a sample item with no sensitive information.
2. Move it into **Ready for review** once.
3. Open monday.com's **Run history** and inspect the HTTP block's input, status code, and response body.
4. Confirm the Ping appears once in the Room history and on one recipient device.
5. Move the item through an unrelated status and confirm no Ping is created.
6. Temporarily use a title longer than PingRoom's 40-character limit and confirm the block records PingRoom's `422` validation response, then restore the valid title.
7. Rotate the webhook secret in the test Room, replace the URL in monday.com, and confirm the old URL no longer works.

A successful PingRoom response is HTTP `200` with `success: true` and a `notification_id`. That means PingRoom accepted and queued the Ping. It does not guarantee what every phone displayed: connectivity, notification permission, Focus settings, Room mutes, and operating-system policy still apply.

For this article, we extracted the exact headers and body above, validated them against PingRoom's documented limits, and sent them to a local mock endpoint. We also simulated two identical deliveries without an idempotency key and confirmed that two Pings can be created. The check used no live monday.com account, PingRoom Room, or recipient phone.

monday.com counts active workflows and executed actions according to the product and plan. Its current [workflow usage guide](https://support.monday.com/hc/en-us/articles/11381357489810-The-AI-workflow-builder-active-workflows-and-actions) documents different active-workflow limits and says workflow actions count toward the account's automation allowance. Confirm the block is available and review the current allowance before connecting a busy board.

If one status deserves a shared phone signal, [create the private Room and incoming webhook](/app/rooms), test the fixed message, and keep monday.com as the place where the work lives.

_monday.com is a trademark of monday.com Ltd. PingRoom is not affiliated with or endorsed by monday.com._