Campaign operations · Practical guide

Cold email campaign not sending: check eligibility before retrying

Start with one affected enrollment. A campaign can be active while a particular contact is paused, not yet due, outside a sending window, or waiting for capacity. Retrying the campaign does not resolve all of those states.

Reviewed 2026-09-15 · Examples are illustrative

Who this helps: Campaign operators investigating a stopped or delayed Zintara sequence.

Separate campaign state from contact enrollment

Importing contacts, adding them to a campaign and activating a sequence are separate operations. In the current sending path, the campaign and enrollment must both be active, and the next send time must be due. An active campaign badge does not establish that every contact has work ready to send.

Pick one affected contact and record the sequence step, state and expected time. If another contact in the campaign is progressing normally, compare the two before changing workspace-wide settings. That comparison often narrows the question more effectively than restarting everything.

Check	Question to answer	Next action
Campaign and enrollment	Are both active?	Review why a paused or completed state exists
Sequence step	Is there a remaining message?	Confirm the intended sequence; do not replay completed steps
Due time	Has the next step become due?	Compare the actual time and schedule
Sending window	Is this an allowed day and time?	Check campaign timezone and window

Compare due time with the allowed sending window

A delay determines when a step becomes due, but the campaign’s allowed days and window can move the actual send later. Check the configured timezone rather than assuming the browser’s local clock is the campaign clock.

In this synthetic example, a step becomes due at 17:30 in the campaign timezone, after a 09:00–17:00 window. If the following day is allowed, the next eligible window starts there. If that day is excluded, the wait is longer. This is a scheduling explanation, not a delivery-time guarantee.

Illustrative schedule
Step due: Monday 17:30, campaign timezone
Allowed window: 09:00–17:00 on weekdays
Next window: Tuesday 09:00
Still required: capacity, eligible mailbox, valid recipient and successful sending

Check capacity and the selected mailbox

Zintara checks workspace and campaign delivery budgets before sending. Each cap uses its respective configured timezone for the daily reset. Reserved or uncertain delivery attempts can consume capacity while their outcome is being reconciled. Do not infer remaining capacity solely from a visible count of successfully sent messages.

The sending engine resolves accounts selected for that campaign. A healthy mailbox elsewhere in the workspace does not establish that this campaign has an eligible sender. Check the selection and connection, then investigate any account-specific restriction. Follow the mailbox guide when authentication is failing.

Raising a cap is not a general troubleshooting remedy. First decide whether the existing limit is behaving as configured. If so, wait for the appropriate window or have the campaign owner deliberately review the plan; do not change multiple limits while diagnosing an unrelated error.

Treat an uncertain send differently from a rejected send

If a worker stops after contacting the mail server but before persisting a definite outcome, blindly retrying can send a duplicate. The current engine tracks attempts and pauses uncertain ones for reconciliation. A paused uncertain attempt is therefore not evidence that the email definitely never left.

Compare the provider’s delivery evidence with the affected enrollment and test time. Preserve message identifiers for authorized support review. Do not clone the campaign or recreate the contact as a shortcut around an unresolved attempt. Resolve what happened first, then choose the appropriate next step.

Record the affected campaign, contact, step and expected send time.
Check for a known rejection versus an uncertain outcome.
Ask support to correlate the attempt with provider evidence if the UI does not expose enough detail.
Resume only after deciding whether the step was already accepted or still needs sending.

Prepare a useful support handoff

Provide a redacted example containing the campaign and enrollment state, selected sender, timezone, window, due time, observed error and any recent change. Distinguish ‘nothing was queued,’ ‘waiting for capacity,’ ‘connection rejected,’ and ‘outcome unknown’ wherever the evidence allows.

If everything looks eligible but no progress occurs, the service operator may need to check worker and queue health. Running containers alone do not prove that a particular delivery job completed. Avoid manual database edits or repeated live sends as a diagnostic substitute.

After recovery, review replies and opt-outs before resuming follow-ups. A technical repair does not mean a previously scheduled message is still appropriate. Use the sequence overview for campaign preparation and the linked inbox guide when reply visibility is part of the problem.

Source: Zintara email sequence overview

Source references

Zintara email sequence overview

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow