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

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 recommends focused notify actions for important status changes.

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 explains the PingRoom response. The incoming-webhook reference 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. 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:

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

Use this body:

{
  "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.

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 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 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:

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 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, 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.