Email Operations4 min read

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
Direct answer

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:

Scroll table →
WindowExpected entry sourcePlanned activityBaseline ready?First owner
First launch dayNew membership formSmall controlled intakeNot enough historyLaunch operations
Ordinary weekdayPublic enrollmentNormal intakeVerify usable historyLifecycle operations
Enrollment closedNone expectedIntentional pauseHistory may still be nonzeroMembership owner
Reopened intakePublic enrollmentNew operating patternOld baseline may misleadLifecycle 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.