Rollbar Automation with Native Tools: Deploys, RQL, Webhooks

If you set up exactly one piece of Rollbar automation this week, make it the deploy notification. It's five lines in your deploy script, and from that moment on every error carries a version — you stop asking "did the release break this?" and start reading the answer off the item page. Everything else in this guide compounds on top of it.

In part one of this series we walked the error-triage reality: item graveyards, spikes vs new vs reactivated items, grouping gone wrong, and deploy tracking as the most underused signal in the product. This article is the hands-on part — building a DIY error-response workflow with only Rollbar's native features: notification rules, the Deploy API, RQL, item statuses, webhooks, and the Versions view. Part three covers what sits above all of it.

Budget an afternoon. Work feature by feature.

Feature 1: Notification rules — route by severity, not by existence

Rollbar's default behavior — notify on every new item — is how Slack channels get muted. The fix is per-channel rules with filters, configured under Settings → Notifications → [channel] (docs).

Each channel (Slack, email, PagerDuty, webhook, and others) gets its own rule set. The triggers that matter:

A routing setup that survives contact with production:

1. New Item → #eng-errors, with filters environment equals production AND level greater than or equal to error. Warnings and staging noise never page anyone.
2. Reactivated Item → same channel, no level filter. A reactivation means a fix didn't hold — that's always worth a human look, which is exactly the argument from part one.
3. High Occurrence Rate → PagerDuty, threshold in the spirit of "50 occurrences in 5 minutes" for a mid-market service. This is your "the release is on fire" wire.
4. Every Occurrence → nowhere, unless it feeds a machine (see webhooks below).

Filters can also match on item title, filename, and framework — useful for routing payment-path errors to the team that owns payments instead of a shared channel everyone has learned to ignore.

Feature 2: Deploy tracking — the five lines that pay for themselves

Deploy tracking does two jobs: it timestamps releases on every graph, and it lets Rollbar attribute occurrences to a code_version so you can see which release introduced an error (docs).

Step one: make your SDK report the version. In server SDKs this is a one-line config, e.g. in Node:

const Rollbar = require('rollbar');
const rollbar = new Rollbar({
  accessToken: process.env.ROLLBAR_TOKEN,
  environment: 'production',
  code_version: process.env.GIT_SHA, // the line that makes deploys correlatable
});

Step two: report the deploy itself from CI, using a post_server_item project access token. With curl (API reference):

curl https://api.rollbar.com/api/1/deploy \
  -H "X-Rollbar-Access-Token: $ROLLBAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "environment": "production",
    "revision": "'"$(git rev-parse HEAD)"'",
    "rollbar_username": "deploy-bot",
    "local_username": "'"$(whoami)"'",
    "comment": "release '"$(git describe --tags --always)"'",
    "status": "started"
  }'

The response includes a deploy_id. For long deploys, PATCH it when you finish, so the timeline shows real deploy windows instead of instants:

curl -X PATCH "https://api.rollbar.com/api/1/deploy/$DEPLOY_ID" \
  -H "X-Rollbar-Access-Token: $ROLLBAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "succeeded"}'

If your pipeline is Node-based, rollbar-cli wraps the same call (and handles source map uploads for browser projects):

npx rollbar-cli notify-deploy \
  --access-token "$ROLLBAR_TOKEN" \
  --environment production \
  --revision "$(git rev-parse HEAD)"

Then turn on the Deploy notification trigger for a #deploys channel. When a High Occurrence Rate page lands three minutes after a deploy message, the correlation does itself.

Feature 3: RQL — investigation queries instead of scrolling

RQL is Rollbar's SQL dialect over raw occurrence data (Dashboard → RQL, docs). It's the difference between clicking through fifty item pages and asking one question.

The noise census — which items dominated production in the last 24 hours:

SELECT item.counter, item.title, count(*)
FROM item_occurrence
WHERE environment = 'production'
  AND timestamp >= unix_timestamp() - 86400
GROUP BY item.counter, item.title
ORDER BY count(*) DESC
LIMIT 20

The deploy autopsy — everything the release with SHA 9f2c1ab has produced, which only works because Feature 2 populates code_version:

SELECT item.counter, item.title, count(*)
FROM item_occurrence
WHERE environment = 'production'
  AND code_version = '9f2c1ab'
GROUP BY item.counter, item.title
ORDER BY count(*) DESC

The blast-radius check — is item #4211 one retry loop or a thousand angry users:

SELECT person.id, count(*)
FROM item_occurrence
WHERE item.counter = 4211
  AND timestamp >= unix_timestamp() - 3600
GROUP BY person.id
ORDER BY count(*) DESC

A short person list with huge counts is a retry loop; a long list with count 1 each is an incident. You can also group by server.host, request.url, or client.javascript.browser to test the usual hypotheses (one bad host, one bad endpoint, one bad browser) in seconds. Save the queries you reuse — RQL supports saved queries per project.

Feature 4: Item statuses — make "resolved" mean something

Items are active, resolved, muted, or archived. The status workflow only pays off when combined with deploy tracking: resolve an item in a version (docs). On the item page, use the status dropdown's Resolve → in version and enter the fixing SHA. From then on, occurrences from older versions (stragglers, un-upgraded hosts) won't reactivate the item — only an occurrence from a version at or after the fix does. Without this, reactivation alerts cry wolf and get muted; with it, a reactivation genuinely means "the fix didn't fix it."

You can drive the same workflow from CI, resolving the items your release notes claim to fix:

# Item IDs differ from the visible counter — translate first
curl -s "https://api.rollbar.com/api/1/item_by_counter/4211" \
  -H "X-Rollbar-Access-Token: $ROLLBAR_READ_TOKEN"

# Then resolve with a write-scope token
curl -X PATCH "https://api.rollbar.com/api/1/item/$ITEM_ID" \
  -H "X-Rollbar-Access-Token: $ROLLBAR_WRITE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "resolved", "resolved_in_version": "9f2c1ab"}'

Two habits complete the loop: mute (not resolve) for known-noisy items you've decided not to fix, so they stay queryable without alerting; and assign an owner on anything left active — an unowned active item is part one's graveyard forming in real time.

Feature 5: Webhooks — occurrence data as an event stream

The webhook channel (Settings → Notifications → Webhook, docs) POSTs JSON to your endpoint for the same triggers as any channel — which means the machine-facing triggers you'd never route to Slack become useful. A new_item payload looks like:

{
  "event_name": "new_item",
  "data": {
    "item": {
      "id": 987654321,
      "counter": 4212,
      "environment": "production",
      "level": 40,
      "title": "TypeError: Cannot read properties of undefined",
      "total_occurrences": 1,
      "last_occurrence": {
        "code_version": "9f2c1ab",
        "request": { "url": "https://api.example.com/v2/checkout" }
      }
    }
  }
}

Other event_name values include reactivated_item, item_velocity (High Occurrence Rate), exp_repeat_item, and deploy. Typical DIY builds on top: auto-create a Jira ticket for every production new_item at error level, post item_velocity events into an incident-management flow, or cross-reference the code_version in the payload against your deploy log and comment the suspect diff link into the ticket. That last one is the closest DIY gets to automated investigation — and it's a script you now own, patch, and debug forever.

Feature 6: The Versions view — regression review in one screen

Versions in the project nav shows each code_version with its deploy metadata, new items, reactivated items, and occurrence trend (docs). It's the release-health review nobody schedules: after each deploy, one glance answers "did this version introduce anything new, and did it resurrect anything old?" Two or more reactivated items on a fresh version is the classic bad-merge signature — check it before the next deploy buries the evidence. This view is entirely powered by Features 2 and 4; without code_version and resolve-in-version it stays empty.

The ceiling: rules route items; nobody reads the stack trace for you

Run this whole setup and you'll have something genuinely better than defaults: severity-routed alerts, version-stamped errors, saved investigation queries, honest reactivations, and a webhook stream feeding your ticketing. You should build it. You should also see its ceiling clearly.

Rules route; they don't reason. A perfectly filtered New Item alert still lands as a title and a link. Deciding whether it's a retry loop or an incident takes the RQL pass above — a human, every time.

Correlation is manual at the exact moment it's needed. The deploy timestamp and the error spike sit on the same graph, but reading the stack trace, opening the deploy diff, and connecting frame to changed line is 20–40 minutes of engineer attention per incident, usually at the worst possible time.

Thresholds drift. The occurrence-rate numbers you pick today are wrong after the next traffic doubling, and re-tuning them is a chore that reliably loses to feature work.

The webhook scripts become a product. The Jira integration, the diff-commenting bot — someone maintains them, and that someone is you.

The setup detects and routes. Investigation and response still run on engineer-hours.

What comes next

Everything after the alert — reading the trace, correlating the deploy, naming the likely cause, proposing the fix or rollback — can be delegated. CloudThinker agents connect to Rollbar read-only, watch new and reactivated items and occurrence spikes, and investigate them with the same evidence you'd use, under graduated autonomy with escalation intact. That's part three of this series. Or see it on your own project first: Try CloudThinker free — 100 premium credits, no card required.