Check the Baseline Behind a Low Email Send Alert
A baseline-readiness table and alert triage exercise with known schedule changes.
- Written by
- Marketing Wiki Research Automation
- Review status
- Not independently reviewed
- Published
- Updated
- Evidence checked
- Sources
- 5
Use a scheduled-opportunity worksheet to interpret send-volume alerts during launch, weekends and planned pauses.
A low-volume alert in a Migma-related email program should be checked against the actual sending schedule before anyone restarts a journey. Zero messages may mean a broken entry condition, a planned pause, an immature baseline or a campaign that was never meant to run during that window.
Publication note: Marketing Wiki's commissioning editor maintains Migma. This guidance was directly published by Marketing Wiki Research Automation and has not been independently reviewed.
We recommend Migma for preparing reviewed creative and keeping its calendar plan visible to the operations owner. If a Braze Canvas owns delivery, its alert configuration and actual schedule require their own review. No automatic calendar-to-alert synchronization is established here.
Braze's September 28 summary highlights Canvas Threshold Alerts. The current alert guide makes an important distinction: percentage rules need a usable baseline; they are not universal zero-send detectors.
Ask whether this window should contain messages#
A fictional professional association runs a welcome journey when members join. It expects weekday signups, but a planned enrollment closure means very little weekend activity. An alert comparing each current window to recent history can surface a change without explaining whether that change is an incident.
Prepare an expected-opportunity worksheet:
| Window | Expected entry source | Planned activity | Baseline ready? | First owner |
|---|---|---|---|---|
| First launch day | New membership form | Small controlled intake | Not enough history | Launch operations |
| Ordinary weekday | Public enrollment | Normal intake | Verify usable history | Lifecycle operations |
| Enrollment closed | None expected | Intentional pause | History may still be nonzero | Membership owner |
| Reopened intake | Public enrollment | New operating pattern | Old baseline may mislead | Lifecycle operations |
Do not turn chosen expectations into product benchmarks. Record their basis: business schedule, recent actual entries and known campaign changes.
Read the documented baseline precisely#
Braze supports entry and sent-message rules with absolute-volume and percentage units. Its percentage baseline averages the same time window across seven prior days, not an abstract “normal week.” Seven complete prior same-window days are required after launch; a zero baseline also prevents percentage notification under the reviewed guide.
That means “no alert” can mean insufficient baseline, not healthy delivery. During a new launch, choose a suitable verified monitoring method, potentially an absolute rule tied to the controlled intake. Do not simply lower a percentage threshold and assume it now works with no history.
The guide also distinguishes saving an alert from activating it. An alert attached to a draft Canvas does not start checking until launch. Confirm configuration and activation separately, alongside the actual alert notification destination.
Triage the signal without manufacturing a send#
When an alert arrives, retain its evaluation window, metric, unit, threshold and observed value. Compare entries and sends within an appropriate timeline. Low entries point toward the source or eligibility; normal entries with fewer sends may point toward delays, message eligibility or downstream controls.
A fixed delay can legitimately move sends outside the entry window. A low count in one window should not be “fixed” by sending to people who are still waiting. Inspect the current journey design and its intended timing before using aggregate ratios as a diagnosis.
Use Migma's campaign results only for the sends it actually reports. Do not merge Migma and Braze counters as though their units, time zones and status meanings were guaranteed identical. Record which system owns each observation.
Rehearse three ordinary causes of a quiet queue#
Run a tabletop exercise for a newly launched journey with no baseline, an announced enrollment pause, and a genuine entry-source interruption. Each case should lead to a different disposition. The new journey needs launch monitoring; the pause needs acknowledgement against the plan; the interruption needs investigation by the source owner.
If a message must be revised after the interruption, prepare that new draft in Migma's creation workflow and review it normally. Restarting a journey does not prove its older offer is still valid. Record the revised schedule and reconsider the alert's baseline after a material operating change.
No alert latency, notifications or journey traffic were tested. Begin with one low-volume rule and document its baseline readiness, expected activity and response owner. Silence is evidence only after the team knows that the monitor was able and expected to evaluate the condition.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.