{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/campaign-send-capacity-waiting-runbook","id":"campaign-send-capacity-waiting-runbook","slug":"campaign-send-capacity-waiting-runbook","title":"Handle Campaign Send Limits Without Duplicating Delivery","description":"Use capacity equations, state-specific actions, and a Waiting runbook when an email campaign reaches daily or monthly sending limits.","dek":"Waiting is not failed. Freeze replacements, reconcile sent and reserved usage, then approve a wait, reduced audience, or capacity increase.","category":"Email Operations","topics":["sending limits","campaign operations","Migma","email queues","incident response"],"publishedAt":"2026-09-03","updatedAt":"2026-09-14","lastVerifiedAt":"2026-09-14","readingMinutes":6,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma Product Changelog","url":"https://docs.migma.ai/changelog?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-send-capacity-waiting-runbook"},{"title":"Migma Send Campaign Documentation","url":"https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-send-capacity-waiting-runbook"}],"wordCount":1013,"body":"When an email campaign reaches an account sending limit, do not label it failed and do not start a replacement campaign. Freeze the intended audience, reconcile sent and reserved usage, identify the platform state, and choose one of three explicit outcomes: wait, send a deliberately reduced remainder, or obtain more capacity.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 3, 2026.\n\nMigma’s August 20, 2026 changelog update introduced clearer campaign-limit handling. Its current [campaign-send documentation](https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-send-capacity-waiting-runbook) says a team can keep preparing work after reaching a daily limit. Before queueing, the product presents wait, send what remains today, or increase limits. A campaign that starts and then reaches the limit shows **Waiting**, not failed.\n\nThat distinction matters because “failed” invites a retry, while “waiting” may mean the original campaign still owns delivery intent.\n\n## Calculate capacity from authoritative counters\n\nUse separate daily and monthly equations:\n\n`available daily = daily limit − sent today − reserved today`\n\n`available monthly = monthly limit − sent this month − reserved monthly work`\n\n`safe campaign capacity = min(available daily, available monthly, policy cap)`\n\nDo not substitute delivered count for sent or reserved usage. Delivery events occur later and answer a different question. Record the counter source, timestamp, timezone, and whether scheduled campaigns reserve capacity.\n\nMigma’s [changelog](https://docs.migma.ai/changelog?utm_source=marketingwiki&utm_medium=referral&utm_campaign=campaign-send-capacity-waiting-runbook) says account-level metrics include current-month sent, delivered, bounced, and complained totals; today’s sent and reserved usage; daily and monthly limits; remaining capacity; and historical months. The documentation establishes the fields, not the exact timing of every counter transition.\n\n## State-response table\n\n| Observed state | What it means operationally | Safe response | Evidence to capture |\n| --- | --- | --- | --- |\n| Draft, over limit before queue | Nothing should be assumed sent | Wait, deliberately shrink, or increase capacity | Draft ID, audience snapshot, counters |\n| Scheduled, capacity uncertain | Future intent exists | Confirm reservation semantics before adding work | Schedule ID, timezone, reserved usage |\n| Sending | Provider has begun work | Do not clone or restart | Campaign ID, accepted/sent counters |\n| Waiting | Original campaign may resume | Freeze replacements; investigate capacity and queue | Transition time, remaining audience, support record |\n| Completed | Platform says processing ended | Reconcile sent, skipped, delivered, and bounced | Final campaign export and timestamps |\n| Failed | Terminal error is documented | Determine scope before retry | Error, last successful recipient/operation, retry plan |\n\nTreat an unfamiliar or contradictory state as unknown. Escalate rather than coercing it into “failed.”\n\n## Decide among the three documented options\n\n### Wait\n\nWait when the content and audience remain valid after the reset, timing is not legally or commercially fixed, and no conflicting campaign will consume the next window. Reapprove the schedule if the date changes the offer, context, timezone, or segment membership.\n\n### Send what remains\n\nA reduced send changes the audience decision. Record the selection rule—highest-engagement cohort, contracted recipients, or another approved priority—before reducing. Never let a convenient table order decide who receives a limited campaign.\n\nCreate an exclusion record for deferred recipients and a plan for whether they should receive the message later. Recompute frequency caps and campaign relevance at that later time.\n\n### Increase limits\n\nMore capacity is a billing and deliverability decision, not merely a button click. Confirm who can approve the change, the effective time, the new daily and monthly ceilings, and whether domain reputation supports the requested volume. Increasing an account allowance does not make a sudden volume spike safe.\n\n## Waiting-state incident runbook\n\n1. **Stop new launches.** Prevent another campaign from consuming capacity or duplicating recipients.\n2. **Capture state.** Record campaign ID, release version, start time, timezone, selected unique audience, counters, and visible status.\n3. **Identify committed work.** Separate queued, accepted, sent, skipped, delivered, bounced, and unknown recipients using provider-supported records.\n4. **Check reset boundaries.** Determine daily and monthly reset time and any scheduled reservations.\n5. **Choose resume policy.** Resume the original only when the remaining audience and content are still valid.\n6. **Reapprove material change.** A new date, smaller audience, different sender, or edited email requires a new release record.\n7. **Close with reconciliation.** Preserve final counts and reasons; do not report waiting recipients as bounces or failures.\n\nUse the [skipped-recipient guide](/articles/skipped-recipient-reconciliation) after completion to separate platform filtering from attempted delivery. Use the [domain rollout guide](/articles/ai-email-domain-rollout) when a capacity change also increases sending volume on a new identity.\n\n## Capacity worksheet\n\n| Field | Value |\n| --- | --- |\n| Account/workspace | Exact production authority |\n| Counter timestamp and timezone | Fresh snapshot |\n| Daily limit / sent / reserved | Three separate values |\n| Monthly limit / sent / reserved | Three separate values |\n| Selected unique recipients | Before capacity decision |\n| Eligible recipients | After consent and suppression |\n| Safe campaign capacity | Minimum of enforced constraints |\n| Decision | Wait, reduced send, or increase |\n| Priority rule | Required for reduced send |\n| Approver | Named person |\n| Resume/reset condition | Observable condition |\n| Deferred-recipient policy | Later send, expire, or suppress |\n\nKeep the worksheet beside the campaign release. A chat message saying “quota hit” is not enough evidence to prevent a duplicate follow-up.\n\n## Test before a high-volume date\n\nIn a non-production environment or with a provider-supported safe fixture, test pre-queue rejection, partial capacity, daily reset, monthly exhaustion, cancellation while scheduled, and the Waiting transition. Confirm notifications and API responses use the same state vocabulary as the dashboard. Do not manufacture real recipient traffic simply to reach a limit.\n\n## Evidence limits\n\nMarketing Wiki did not exhaust a Migma account or observe a Waiting campaign. Exact limits vary by plan and agreement. Documentation does not establish queue ordering, reservation timing for every campaign type, automatic resume timing, or whether a particular increase is deliverability-safe. Treat those as test or support questions before relying on automation."}