Cron for analysts: how five cadences (hourly, daily, weekly, monthly, on-anomaly) actually perform
How often should a metric be pulsed? Data from thousands of scheduled Slack deliveries: when each cadence wins, when it fails, and the most underused option of the five.
TL;DR
Of the five common pulse cadences — hourly, daily, weekly, monthly, on-anomaly — daily wins for most business metrics, weekly is underused for trend metrics, on-anomaly is the most underused option overall and has the best long-term reaction rate, hourly has the lowest survival rate (38% turned off within 30 days), and monthly is right for stable indicators but wrong as a default.
The metric is right, the recipients are right, the format is right. The thing most teams still get wrong is the cadence.
This post lays out how the five common cadences actually perform in the data, when each one wins, and what to do when you're not sure.
The five cadences
For purposes of this analysis:
- Hourly — fires every hour, or every N hours
- Daily — fires once a day at a fixed time
- Weekly — fires once a week at a fixed time
- Monthly — fires once a month at a fixed time
- On-anomaly — fires only when the underlying metric breaches a threshold (absolute or learned)
There are exotic options (event-driven, cron-string, "first business day of the month") but they reduce to one of the five for purposes of how the recipient experiences them.
Reaction-rate by cadence
Aggregated across the active Chartcastr pulse population, reaction rate per delivery looks roughly like this:
| Cadence | Reaction rate per delivery | Survival to 90 days |
|---|---|---|
| Hourly | 4% | 62% |
| Daily | 18% | 87% |
| Weekly | 31% | 92% |
| Monthly | 24% | 89% |
| On-anomaly | 41% | 94% |
Two things stand out.
On-anomaly has the best reaction rate. This is mechanical: every delivery is, by construction, a deviation. Nothing is uneventful. The reader has been trained that when this pulse fires, something is worth attention.
Hourly has the worst. Most hourly deliveries arrive when nothing has materially changed. The reader's brain learns to skip them within the first week. By the 30-day mark, 38% have been turned off entirely.
Daily: the right default, but not the universal answer
Daily is the cadence to default to for business metrics where the day-over-day signal carries information. Revenue, AR, pipeline coverage, support volume, daily active users. These metrics move enough day-to-day that a daily delivery has something to say.
The failure mode of daily is over-application. A team rolls out push analytics, sets every pulse to daily, and within a month is sending eight deliveries per day to the same channel. The Slack channel becomes noise.
The discipline is to ask, for each metric: does this number meaningfully change on this cadence? If the answer is no, move it to a slower cadence.
Weekly: the most underused cadence
For trend metrics — anything where you care about the slope more than the level — weekly outperforms daily. Returning customer rate, AOV trend, support response time, NPS, MRR roll-up: all of these are trend metrics. A daily version is mostly noise; a weekly version is signal.
The choice of day matters. From the Slack chart delivery engagement benchmark, Tuesday is the best day for any new weekly pulse (71% read-within-24h vs 63% for Monday). Most teams default to Monday because it's the obvious choice — but Monday is triage day. By Tuesday, the team is forward-looking and the read-rate jumps.
Monthly: right for stable indicators, wrong as a default
Monthly is the right cadence for indicators that move slowly enough that a daily or weekly pulse would be empty noise. Runway. Cohort retention curves. Quarterly plan tracking. Strategic-tier KPIs.
The failure mode of monthly is using it as the default — "we'll send a monthly summary." A monthly summary of metrics that should be daily is a worse version of a dashboard. The reader sees the data once a month, can't act on most of it because too much has happened, and the report becomes a wallpaper-style "look at this" rather than a tool.
If you're tempted to set a metric to monthly, ask: will the recipient be able to act on this with month-old context? If no, the cadence is wrong.
On-anomaly: the most underused cadence overall
On-anomaly fires only when the metric breaches a threshold — either a static one ("AR over $250k") or a learned one ("today's value is more than 3 standard deviations from the trailing seven-day mean").
Three reasons it's underused:
- It requires defining the threshold. This is more work than picking a daily time.
- It feels less "real" — there's no daily delivery to point at.
- Teams worry the pulse will go silent if the threshold isn't right.
But the data is unambiguous: on-anomaly has both the highest reaction rate and the highest survival rate of any cadence. When it fires, the team acts. When it doesn't, the team isn't being interrupted.
The right pattern for many metrics is daily + on-anomaly side-by-side: a routine daily delivery to keep the team aware, plus an anomaly-cadence pulse that fires on breach with a louder format (e.g. tagging the on-call). This is the model for inventory low-stock, error rates, AR aging, and security events.
Hourly: only for operations, never for routine
The only legitimate use cases for hourly cadence are operational windows: an active launch, an ongoing incident, a Black Friday / Cyber Monday peak. In these cases, hourly pulses act as situational awareness for the duration of the window.
Outside those windows, hourly cadence is wrong. The data is brutal: 38% of hourly pulses are turned off within 30 days. Of the rest, most see reaction rates below 5%. The reader cannot context-switch that fast.
If you find yourself reaching for an hourly cadence outside an active window, the pulse you actually want is probably on-anomaly with a tight threshold.
A decision tree
When deciding cadence for a new pulse, in order:
- Does it need to fire only when something changes? → on-anomaly.
- Will the recipient act on month-old context? → if yes, monthly (rare).
- Is the day-over-day movement noise, but the week-over-week is signal? → weekly.
- Does the metric meaningfully change daily, and does the recipient need to act within a day? → daily.
- Are we in an active operational window (launch, incident, BFCM)? → hourly, with a hard end date.
If none of these fit, default to weekly. Most teams who default to daily would be better served by weekly.
What this means for cadence design
Three concrete changes most teams should make:
- Audit your daily pulses. Take the list of pulses currently set to daily; move the trend-metric ones to weekly. Read-rates will rise.
- Add on-anomaly variants for any metric where you have a threshold the team genuinely cares about. Pair them with the daily, don't replace it.
- Set a hard end date on hourly pulses. If you launch an hourly pulse for BFCM, schedule it to switch off on the Monday after.
Pulse configuration in Chartcastr supports all five cadences plus arbitrary cron strings; the pulse builder recommends the cadence by default based on the metric type.
