How to Send a PostHog Event Alert to a Shared Team Phone

Create an HTTP Webhook destination in PostHog, filter it to one exact event and property, send fixed copy to a private PingRoom Room, and use PostHog's event.uuid for both the Idempotency-Key header and correlation_id. That gives a small team one shared phone signal without putting person or event properties on the lock screen.

The worked example below listens only for an illustrative signup_completed event whose environment property is production. It sends New production signup — Open PostHog to review the event. Substitute an event your product already captures and whose meaning your team has agreed on.

PostHog remains the analytics record. PingRoom is the attention path. This is a webhook recipe you configure, not a native PostHog integration, and a Ping does not prove that someone investigated the event.

Decide whether the event belongs on a shared phone

PostHog's realtime destinations can filter by event type and properties before sending anything. Use that filter aggressively. A shared Room is a poor destination for page views, every click, or an event whose owner and next action are unclear.

The example deliberately omits email, name, distinct ID, plan, IP address, URL, and every other event property. The phone only says that the selected event occurred and where to inspect it.

Prepare the Room and protect its webhook URL

In PingRoom, create or choose a private Room whose members want this signal. The Room owner needs PingRoom Pro for incoming webhooks. Open Settings → Connections → From another app, add a webhook, and leave Quick Ping on Custom message.

Copy the complete webhook URL. It contains the credential. Anyone who can read that URL may be able to send to the Room, so limit PostHog project access, do not paste it into tickets or screenshots, and regenerate the PingRoom webhook secret if it leaks.

The incoming-webhook walkthrough covers Room setup. The webhook reference carries the current request fields, text limits, cooldown, idempotency behavior, and responses.

Create one narrow PostHog destination

PostHog's current Webhook destination guide uses this path:

1. Open Data pipelines.
2. Select + New → Destination.
3. Find Webhook and choose + Create.
4. Give the destination a narrow name such as Production signup → shared Room.
5. Paste the PingRoom incoming webhook URL into Webhook URL.
6. Leave the method on POST.

Before enabling it, add two filters:

• Event name equals signup_completed.
• Event property environment equals production.

Those values are examples, not PostHog defaults. Use the exact event and property values your own instrumentation emits. Do not create a second, slightly different analytics event merely to make this recipe work.

Map fixed copy and one replay identity

PostHog destinations support curly-brace templates, and the destination global object includes event.uuid, the unique ID of the event. Configure the request like this:

Use this JSON body:

{
  "action": null,
  "title": "New production signup",
  "message": "Open PostHog to review the event.",
  "correlation_id": "posthog-{event.uuid}"
}

Do not insert {event}, {person}, {event.distinct_id}, or event properties. The destination does not need them to tell the team that the selected event occurred.

The same PostHog UUID appears in the header and body for two different jobs. PingRoom uses the header to make an exact retry idempotent; correlation_id preserves the source identity for connected systems. Reuse the same body with the same key. A genuinely different PostHog event receives a different UUID and may create a new Ping.

PostHog's open-source Webhook destination template confirms that the destination accepts configurable JSON, headers, method, and URL. No custom relay is needed for this fixed-copy route.

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

Pingo has taken responsibility for staring at the stopped duplicate. He cannot access PostHog, enter a private Room, or send a Ping. People choose the event, audience, copy, and response policy.

Test a harmless event before enabling real traffic

PostHog includes a destination testing interface. Use Start testing → Test function with a recent safe sample that matches your filter. Check four things:

1. PostHog records a successful destination invocation.
2. PingRoom creates one Ping with exactly the fixed title and message.
3. The same event UUID and body do not create a second Ping when retried.
4. A different event name or non-production property does not reach the Room.

Inspect the PostHog destination's logs after the test, then keep response logging off unless you are actively diagnosing a harmless request. Never copy the full PingRoom URL into a public log or support thread.

For this article, we rendered the documented header and body templates against filtered, replayed, distinct, malformed, and private-data-rich fixtures. A local PingRoom contract mock checked the final method, body, idempotency header, success, and downstream failure path. No live PostHog project, destination, PingRoom Room, phone, customer data, or delivery was used.

Read retries and success honestly

PostHog says eligible non-OK destination calls may be retried up to three times, depending on the error. That policy can change, so use the destination logs rather than assuming an attempt count. PostHog may quarantine and eventually disable a destination that stays slow or unhealthy.

The stable event.uuid prevents those exact retries from creating another Ping when the body stays the same. It does not promise exactly-once delivery across every possible edit, replay, or configuration change. If you change the phone copy for an already-used key, use a new key or document the migration first.

An HTTP 200 from PingRoom means the request was accepted and the Ping was created. Connectivity, Room mutes, notification permissions, Focus settings, and operating-system policy still affect what appears on each phone. Keep PostHog as the event record and investigation surface.

Check the usage boundary

PostHog's current Data Pipelines pricing lists 10,000 destination trigger events free each month before usage pricing. Pricing changes, and every matching event is a trigger event, so confirm the current page and estimate volume from your actual filter before enabling a noisy destination.

PingRoom's separate requirement is the Room owner's active Pro plan for incoming webhooks. Keep both product boundaries in the runbook; one product's free allowance does not change the other's plan requirement.

When the harmless rehearsal passes, open PingRoom, create the private destination Room, and enable the single PostHog event your team has agreed to act on. Keep the evidence and exploration in PostHog; keep the Room signal short.

PostHog is a trademark of its owner. PingRoom is not affiliated with or endorsed by PostHog.