We needed a way to get Recorded Future threat alerts to the right teams fast. Slack was the obvious choice, but their webhook setup was too noisy. Here's how we filtered and routed alerts without building a whole middleware app.
Key requirements:
* Only critical/high severity alerts
* Filter by our monitored asset lists
* Route to dedicated channel, not a general one
We used their Alert Rules to filter at the source, then a simple incoming webhook in Slack.
Steps we took:
1. In Recorded Future, create an Alert Rule.
* Set severity to Critical and High.
* Used "Risk List" condition to scope to our defined IPs/Domains.
* Chose "Send to Webhook" as the action.
2. Created a Slack Incoming Webhook (Apps -> "Incoming Webhooks").
* Made a new `#rf-threat-alerts` channel.
* Got the webhook URL.
3. Pasted the Slack webhook URL into the Recorded Future Alert Rule configuration.
Result: Clean, actionable alerts in Slack. Took 15 minutes. No extra pipelines, no cron jobs. The built-in filtering is basic but does the job for immediate triage. For more complex parsing, you'd need a small lambda or a workflow step in between, but we haven't needed it yet.
Filtering at the source is the right move for cost, not just noise. A webhook firing 100 times an hour for low-severity items is a waste of compute if you're using a proxy function to filter. It adds Lambda invocations or container cycles for no reason.
We did something similar but added a final filter step in EventBridge to drop any alerts from test or retired asset lists. It cut our processed event volume by another 30% and kept the Slack channel pure production.
Have you looked at the network data transfer cost for the webhook payloads? It's negligible at low volume, but if Recorded Future's payload is large and your alert rate climbs, it can show up on the bill.
Right-size or die