The failure mode with alerts is never that you missed the notification. It is that by the time the one that mattered arrived, you had been receiving three a day for a month and had trained yourself to swipe them away without reading. Alert fatigue is not a discipline problem. It is a configuration problem, and on a macro composite it is a particularly easy one to create because the number moves every single day whether or not anything happened.
The Global Liquidity Scorecard composite sits on a 0 to 100 scale and read 85 when I captured it. Left to its own devices it will drift by a point or two constantly. If your alert condition is anything close to "the score changed", you have built a machine that tells you the number is a number.
What actually updates, and how often
Before setting any threshold, look at what is underneath. GLS blends the aggregate central bank balance sheet, global M2 money supply, USD liquidity indicators and credit spreads across eight central banks. Those publish on completely different calendars. The credit spread and USD liquidity legs move continuously. Balance sheet statements arrive on institutional schedules, weekly at fastest. Money supply is monthly and describes a month that has already ended.
This has a direct consequence for alerting that most people never think through. If the leg you actually care about updates once a month, then any alert capable of firing more than once a month on that leg is firing on something else. Usually it is firing on the daily credit spread component wobbling, dressed up as a liquidity signal. You will act on it, be wrong, and blame the composite.
The four fields that decide whether an alert is useful
Blockcircle's alerting is a multi condition builder. Each rule is a set of conditions joined with AND logic, plus a timeframe, a window, and a cooldown, delivered to email, Discord, Telegram or a webhook. Those are the levers, and for a macro composite the two that matter most are the ones people leave on default.
The condition is what you think is worth knowing. Almost always a level crossing or a sustained direction, never a raw change.
The window is how long the condition has to hold. On a slow series this is your main noise filter.
The cooldown is how long the rule stays quiet after firing. On a slow series this is what stops one piece of information generating four notifications.
The channel is where it lands, and the rule I follow is that slow signals go to slow channels. A macro liquidity read should arrive by email, not as a phone notification. Nothing about a monthly data series requires you to know within ninety seconds, and putting it on a channel that interrupts you trains exactly the reflex you are trying to avoid.
Band crossings need two lines, not one
Say you decide 70 is meaningful on the 0 to 100 scale, so you set an alert for the composite crossing below 70. The composite drifts to 69, fires, drifts to 71, drifts to 69 again, fires again. Three fires in a week and nothing happened.
The fix is a deadband, and it is the single highest value change you can make. Use two lines instead of one. The alert fires when the composite crosses below 70, and it does not re-arm until the composite has recovered above 75. Now the score has to travel five full points to generate a second notification, and the oscillation that produced three fires produces one.
On where to put the lines, I want to be straight with you. I am not going to hand you levels dressed up as product defined bands, because they are not. They are a choice, and the right way to make it is from your own recorded history. Keep a daily column of the composite for two months, look at the range it actually occupied, and put your lines at the edges of that range rather than at round numbers you picked because they were round. Thirds of the scale, at 33 and 67, are a defensible starting frame while you accumulate history, and a starting frame is all they are.
Sustained slope instead of a single reading
The second condition worth building is direction, and it should never be based on one tick. A useful form is: the composite is lower than it was N readings ago by at least M points, and has not made a new high within the window.
Concretely, something like a drop of ten or more points across ten consecutive readings will catch a genuine deterioration and will ignore ordinary drift. The two numbers trade off against each other in an obvious way. Fewer readings and a smaller drop gives you earlier warning and more false ones. More readings and a larger drop gives you fewer, later, and more reliable. Since you are running a macro overlay rather than a day trade, err long on both.
Set the window on this rule to at least the length of the lookback. A slope condition with a window shorter than its own lookback can satisfy itself on a single day of data, which is not what you meant.
The cooldown is the setting that saves you
Here is the rule I would most like you to take away. Set the cooldown to at least the publication interval of the slowest input you are keying on.
If your alert is really about the money supply leg, that leg updates monthly, so a cooldown under a month means the same monthly print can generate multiple notifications as the composite settles around it. If it is about the balance sheet leg, a week is the floor. If it is genuinely about funding conditions, then daily is legitimate, but be honest with yourself that you have built a funding alert and not a liquidity alert, and name it accordingly.
Put together, the whole configuration for a macro composite is three rules, not thirty.
- Composite crosses below your lower line, re-arming only above the line plus five. Window a few days. Cooldown one month. Email.
- Composite crosses above your upper line, same deadband structure in reverse. Same window and cooldown. Email.
- Sustained decline of ten or more points across ten readings. Window ten readings. Cooldown one month. Email.
Three rules that between them should produce a handful of notifications a year. That number is not a sign the alerts are broken. On a macro liquidity read, a handful a year is roughly how often the underlying state genuinely changes, and an alerting setup that fires more than that is telling you about its own settings rather than about the world.