Send Rollbar New-Item Alerts to Your Team's Phones

To send one selected Rollbar New Item alert to your team's phones, point a Rollbar webhook rule at a narrow server-side relay, accept only a production error for one project, and forward fixed copy to a PingRoom incoming webhook. Keep the item title, occurrence data, stack trace, host, user, metadata, and investigation link in Rollbar.

This is a webhook recipe written by PingRoom, not a native Rollbar integration. The destination Room's owner needs PingRoom Pro. Rollbar remains the source of truth. Keep your established pager, acknowledgement flow, escalation policy, and incident record for critical systems.

Choose the route that owns the response

Rollbar supports project-level notification rules for new items, occurrences, item velocity, reopened or resolved items, deployments, and other events. A phone should not receive every event.

This guide uses the first route. It accepts only new_item for one project where the item environment is production and its latest occurrence level is error.

For an illustrative setup, imagine a small product team that wants one private Room to know when Rollbar creates a selected production error item. Pingo the Pigeon, PingRoom's fictional CMO, appears in the artwork beside the gate. He cannot open Rollbar, read the Room, choose the rule, or send a Ping. The human team owns the configuration and every claim.

Create the PingRoom connection

Create or choose a private Room for the people who should receive the signal. Open Settings → Connections → From another app, add an incoming webhook, and leave Quick Ping on Custom message. Use Test once, then copy the complete webhook URL into protected server-side configuration.

The incoming-webhook walkthrough covers the Room setup. The webhook reference lists the current request fields, idempotency behavior, cooldown, rate limits, and errors.

Treat the complete PingRoom URL as a credential. Store it as PINGROOM_WEBHOOK_URL. Do not put it in source control, client code, screenshots, or logs.

This recipe sends only fixed copy:

{
  "action": null,
  "title": "Rollbar new error",
  "message": "Open Rollbar to review the selected production item"
}

No item title, exception message, route, user, host, stack frame, metadata, account name, or Rollbar URL reaches the phone.

Configure one Rollbar rule

In Rollbar, open the project, then go to Settings → Notifications → Webhook. Set the webhook URL to your relay's public HTTPS endpoint and enable the integration. The last path segment is a randomly generated secret:

https://relay.example.com/rollbar/<high-entropy-secret>

Add a New Item rule. Use Rollbar's rule filters to limit it to the intended production environment and error level. Rollbar's current notification guide lists the available filters and recommends care with noisy rules such as Every Occurrence.

Keep the production rule quiet until the relay's rejection cases pass. Rollbar's webhook guide documents the event names, payloads, accepted response codes, delivery history, retries, and automatic shutoff for failing rules.

Treat the URL token as a bearer credential

Rollbar recommends putting an authentication token in the configured webhook URL and checking it at the receiver. Its documented webhook contract does not provide a body signature.

The secret path in this recipe is therefore a revocable bearer credential, not cryptographic proof that Rollbar sent the request. Generate at least 32 URL-safe random characters. Store the same value as ROLLBAR_WEBHOOK_SECRET, keep request URLs out of logs, and rotate the route if it leaks. If your threat model requires signed sender proof, use an approved gateway or a destination with a stronger documented sender-verification mechanism.

Filter before forwarding

This dependency-free Node handler checks the secret path, request size, one Rollbar project, new_item, production environment, error level, and stable item/activation identities. It never maps Rollbar's diagnostic payload into the Ping.

import { timingSafeEqual } from "node:crypto";

const MAX_BODY_BYTES = 64 * 1024;
const FIXED_PING = Object.freeze({
  action: null,
  title: "Rollbar new error",
  message: "Open Rollbar to review the selected production item",
});

function required(name, env) {
  const value = env[name];
  if (typeof value !== "string" || value.length === 0) {
    throw new Error(`Missing ${name}`);
  }
  return value;
}

function validSecret(supplied, expected) {
  if (!/^[A-Za-z0-9_-]{32,128}$/.test(expected)) {
    throw new Error(
      "ROLLBAR_WEBHOOK_SECRET must be 32–128 URL-safe characters",
    );
  }
  const received = Buffer.from(supplied ?? "", "utf8");
  const wanted = Buffer.from(expected, "utf8");
  return received.length === wanted.length && timingSafeEqual(received, wanted);
}

function pathSecret(request) {
  const segments = new URL(request.url).pathname.split("/").filter(Boolean);
  return segments.at(-1);
}

export async function handleRollbarRequest(request, env = process.env) {
  if (request.method !== "POST") {
    return new Response("Method Not Allowed", {
      status: 405,
      headers: { Allow: "POST" },
    });
  }

  if (
    !validSecret(pathSecret(request), required("ROLLBAR_WEBHOOK_SECRET", env))
  ) {
    return new Response("Not Found", { status: 404 });
  }

  const declaredLength = Number(request.headers.get("content-length"));
  if (Number.isFinite(declaredLength) && declaredLength > MAX_BODY_BYTES) {
    return new Response("Payload Too Large", { status: 413 });
  }

  const rawBody = Buffer.from(await request.arrayBuffer());
  if (rawBody.length > MAX_BODY_BYTES) {
    return new Response("Payload Too Large", { status: 413 });
  }

  let payload;
  try {
    payload = JSON.parse(rawBody.toString("utf8"));
  } catch {
    return new Response("Bad Request", { status: 400 });
  }

  const expectedProject = Number(required("EXPECTED_ROLLBAR_PROJECT_ID", env));
  if (!Number.isSafeInteger(expectedProject) || expectedProject <= 0) {
    throw new Error("EXPECTED_ROLLBAR_PROJECT_ID must be a positive integer");
  }

  const item = payload?.data?.item;
  const accepted =
    payload?.event_name === "new_item" &&
    item?.project_id === expectedProject &&
    item?.environment === "production" &&
    item?.last_occurrence?.level === "error";
  if (!accepted) {
    return new Response(null, { status: 204 });
  }

  const itemId = item?.id;
  const activationId = item?.activating_occurrence_id;
  if (
    !Number.isSafeInteger(itemId) ||
    itemId <= 0 ||
    !Number.isSafeInteger(activationId) ||
    activationId <= 0
  ) {
    return new Response("Missing event identity", { status: 422 });
  }

  const webhookUrl = new URL(required("PINGROOM_WEBHOOK_URL", env));
  if (webhookUrl.protocol !== "https:") {
    throw new Error("PINGROOM_WEBHOOK_URL must use HTTPS");
  }

  const eventKey = `rollbar:${expectedProject}:new_item:${itemId}:${activationId}`;
  const response = await fetch(webhookUrl, {
    method: "POST",
    redirect: "error",
    headers: {
      "Content-Type": "application/json",
      "Idempotency-Key": eventKey,
    },
    body: JSON.stringify({ ...FIXED_PING, correlation_id: eventKey }),
  });
  const result = await response.json().catch(() => null);
  if (!response.ok || result?.success !== true) {
    throw new Error(`PingRoom delivery failed: HTTP ${response.status}`);
  }
  return Response.json({ delivered: true }, { status: 202 });
}

Wire the handler to the relay route shown above. Set EXPECTED_ROLLBAR_PROJECT_ID to the numeric project ID in the Rollbar payload. Use a runtime that provides the standard Request, Response, and fetch APIs. Reject oversized bodies at the network edge where possible, and keep raw bodies and request URLs out of logs.

Why fixed copy is safer

Rollbar's item payload can contain a title, occurrence body, exception message, route, user data, server details, framework, metadata, code context, local variables, and an investigation URL. Those fields belong in Rollbar. They are a poor default for a lock screen.

The relay reads only the fields needed to decide whether this event belongs to the selected route. It forwards no Rollbar text or URL. If a second rule needs different fixed copy, add a separate tested allowlist entry instead of falling back to arbitrary payload fields.

The project, item, and activation occurrence IDs become one PingRoom Idempotency-Key. An exact Rollbar retry therefore reuses the same key and body. PingRoom's idempotency receipt protects the normal immediate retry window; it is not a permanent error ledger. Keep Rollbar's item and webhook history authoritative.

Rehearse the boundaries

Rollbar's integration guide suggests first inspecting a test webhook, then triggering a representative event. Use a non-sensitive test project or safe fixture and check these cases before enabling the production rule:

1. One matching new_item event produces the fixed Room Ping.
2. Replaying the same item and activation occurrence reuses the same idempotency key and body.
3. A missing or incorrect path secret returns 404 and sends nothing.
4. A non-POST, oversized body, or malformed JSON is rejected.
5. A different project, event name, environment, or level sends nothing.
6. A missing item or activation identity fails instead of inventing retry identity.
7. A PingRoom error fails visibly, and the relay refuses redirects.
8. A locked test phone shows only the approved fixed copy.

The local fixture for this article passed the first seven deterministic checks against a mocked PingRoom endpoint. It also confirmed that representative item titles, exception messages, routes, user values, hosts, metadata, and Rollbar URLs never entered the outbound body. No live Rollbar project, PingRoom Room, or physical phone was used.

Respond in time, then read the result conservatively

Rollbar accepts 200, 201, 202, or 204 from the receiver. Its current guide says the endpoint has three seconds to respond; other responses or timeouts can be retried up to ten times with exponential backoff. Rollbar records attempts in the rule's history and can disable a rule after permanent or repeated failures.

This example waits for PingRoom before returning 202, so keep the relay close and bounded. If real traffic cannot reliably finish within Rollbar's window, place an idempotent durable queue between receipt and forwarding, acknowledge only after enqueue succeeds, and keep queue ownership and failure handling explicit.

The useful claim is narrow: a request with the correct secret path matched the selected Rollbar project and event fields, and PingRoom accepted the bounded shared signal. Because the webhook uses a bearer token rather than a documented signature, that is not cryptographic proof of Rollbar origin. It also does not mean a phone displayed the Ping, the error still exists, someone acknowledged it, or an incident was resolved.

For service ownership and severity design, read how to route monitoring alerts. When the small shared-signal case fits, open PingRoom Rooms, create the private destination Room, deploy the relay, and pass the boundary checks before enabling the production rule.