Skip to main content
RBLTracker (Generator Labs) monitors whether your mail server IPs and domains appear on RBL blocklists. It also offers certificate monitoring and monitoring agents. Through its webhooks, you can send these events to Flashduty On-call:
  • A host is listed on, or delisted from, a blocklist
  • A certificate is about to expire, has errors, keeps changing fingerprint, or was replaced
  • A monitoring agent stops checking in
Events that come in trigger and resolve pairs map to one Flashduty alert: the trigger event opens it, and the paired resolve event recovers it.

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select RBLTracker, then click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select RBLTracker and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure RBLTracker

1

Add a webhook

Where: RBLTracker (Generator Labs) Portal › Development › Webhooks › Add WebhookSave when done.
Select each trigger event together with its resolve event. Otherwise the alert does not recover. For example, if you select rbl.host.listed without rbl.host.delisted, the Flashduty alert stays open after the host is delisted.
You do not need to select billing events (billing.*) or rbl.host.check.started and rbl.host.check.completed. Flashduty acknowledges them with a success response but creates no alert.
2

Send a test and verify in RBLTracker

Where: RBLTracker (Generator Labs) Portal › Development › Webhooks › Send TestIn the Webhooks list, click Send Test on the webhook, choose an event type from the Event drop-down, and click Sent Test Request (spelled this way in the official docs). RBLTracker shows the response code and timing; 200 means the URL is reachable. Send Test only proves connectivity and creates no alert in Flashduty.Send Test sends the selected event about placeholder objects (host Test Host at 127.0.0.2, certificate monitor example.com, agent Test Agent) and uses a new random SID for every object on every send. Flashduty recognizes these placeholders, returns success and creates no alert.To verify the full lifecycle, add a test host that you know is listed, confirm that Flashduty shows an active alert for rbl.host.listed, and confirm that the alert recovers after the host is delisted.

Alert key

Flashduty uses the SID of the object in the RBLTracker event as the Alert Key, with a prefix per event category: In the official RBLTracker API reference, rbl.host.listed and rbl.host.delisted for one host carry the same host.sid, certificate events carry monitor.sid, and agent events carry agent.sid. cert.flapping is described only in prose, without a full example, so Flashduty reads monitor.sid from it as it does for the other certificate events. Changes to the host name, the number of blocklists, the check SID (check_sid), or the event SID (event_sid) never change the Alert Key. An event without the matching SID is rejected, and so is a cert.changed event without new_fingerprint.

Status and severity

The event type sets the alert status; the table above shows which events recover. RBLTracker does not send a severity, so Flashduty sets it by event type:

Auto-close for one-shot events

cert.changed is a single notification, and RBLTracker never sends a matching resolve event. Each certificate replacement on a monitor creates its own alert, and these alerts do not recover on their own. Turn on the auto-close timeout for the channel and set it to 24 hours.

Labels

Delivery and retries

RBLTracker sends application/json POST requests, and a 2xx response from Flashduty counts as delivered. A failed delivery (non-2xx, timeout, or connection error) is retried after 30 seconds and again after 2 minutes with the same event SID, so retries do not create duplicate alerts. After 10, 20, and 30 consecutive failures RBLTracker pauses the webhook for 1 hour, 6 hours, and 1 day; after 40 it disables the webhook and you must re-enable it under Development → Webhooks. Every delivery carries an X-Webhook-Signature header. Flashduty authenticates requests with the integration_key in the push URL and does not verify that header.

Troubleshooting

  • RBLTracker shows a failed delivery: confirm the URL is complete and includes integration_key, and check the response code in the Send Test result
  • Flashduty returns an invalid parameter error: the body must be an RBLTracker JSON delivery; events without host.sid, monitor.sid, or agent.sid are rejected
  • The alert does not recover: confirm you also selected the matching resolve event. cert.error.resolve recovers the alert only when current_errors is empty, and cert.changed never recovers, so turn on auto-close
  • The alert updates repeatedly while the host is listed: the API reference says rbl.host.listed is sent when a check finds the host listed; repeated deliveries for one host merge into the same alert
  • The webhook was disabled: RBLTracker disables a webhook after 40 consecutive failures. Fix the URL and re-enable it under Development → Webhooks
For field details, see RBLTracker Webhooks and the Webhook API reference.