Farbeam

Alerts that matter

2026-11-04 UTC · Farbeam research

Most alert channels get muted within a week. The cause is usually simple: the rule fires often, and nobody has a reason to act on any single message. This guide shows how to write a rule that survives. The examples use Beamline, and the thinking applies to any alert system.

#Start from the action

Write down what a person does when the alert fires. If you cannot name an action, you do not need an alert. You may want a dashboard or a daily summary instead.

AlertActionWorth an alert
Any USDC transfer above $100,000NoneNo
Your treasury address sent more than $100,000Confirm that the transaction was plannedYes
Your token left a known bridge contractCheck the bridge status pageYes, if you operate on that bridge
A labeled exchange received $1,000,000 of ETHNone for most teamsRarely

#Measure before you save

A threshold chosen by feel is usually wrong. Test the rule against real rows first. The rule tester and POST /rules/validate run an expression on the newest 2,000 stored transfers and report the match count.

On 2026-11-04 at 19:21:20Z, these rules ran against 1,948 rows, which was about 18 minutes of data:

RuleMatchesRate per hour at that pace
chain == "base" and usd >= 250k487About 1,600
usd >= 5m and token in ["USDC","USDT"]18About 60
chain == "base" and usd >= 1m and kind == "token"4About 13
to_type == "exchange" and usd >= 1m1About 3

That is a short sample, so treat the rates as rough. The lesson still holds: moving from $250,000 to $1,000,000 cut the Base rule by over 100 times. Most of the noise sits at the lower end.

A channel that a person reads can handle a few messages per hour. If your test shows more, raise the threshold or narrow the rule.

#Narrow by what you know

The best rules use a specific address. A rule on one address fires rarely, and each message means something.

Beamline
from == "0x5754284f345afc66a98fbb0a0afe71e0f007b949" or to == "0x5754284f345afc66a98fbb0a0afe71e0f007b949"

The next best option is a type field, because it adds meaning from the label set:

Beamline
to_type == "bridge" and usd >= 1m

Least useful is a plain value threshold across all chains. Value alone says something moved. It says nothing about why it matters to you.

#Watch for rows that are not what they seem

Several things produce large rows with no economic meaning.

A rule can remove some of these with not:

Beamline
usd >= 5m and not from_type == "dex" and not to_type == "dex"

#Plan for misses

Every alert system misses things. Know how yours does. On Farbeam:

So for anything important, add a second check that does not depend on the alert. A scheduled job can call GET /wallets/{address} and compare tx_sent with the last value. That number changes when an account sends anything, whatever the size. The alerts page has the full list.

#Check the channel itself

An alert channel that goes quiet looks the same as a calm market. Once a week, send a test delivery with POST /rules/{id}/test, and read the delivery log. Check that the rule is still enabled, since it can turn off by itself.

#Handle duplicates

Your endpoint can receive the same event twice, if it replied late. Store data.uid, and ignore a value you have seen. Reply with a 2xx within 6 seconds and do slow work afterwards.

#A short review list

Before you save a rule, confirm these points.

  1. You can name the action a person takes.
  2. You ran it in the rule tester and know the rough rate.
  3. The rate is low enough for a person, and the cooldown will not hide a match you need.
  4. You verify the signature and remove duplicates.
  5. Someone reviews the rule every month and deletes it if it led to no action.

An alert tells you that a public event happened. It does not tell you what to do about a market, and it is not financial advice.