How do I know this will not happen again?

Two layers of protection. First, an automatic regression test in our build pipeline that seeds the exact bug scenario (a finished campaign with permanent records but no temporary queue rows) and asserts the counter reads correctly. Any code change that would re-introduce the bug fails the test before it ships. Second, a continuous drift detector — a background job that scans every email and multichannel campaign every hour and flags any campaign whose dashboard counter is more than 5 sends below the real count. If even one campaign trips the threshold, our internal monitoring fires an alert. The detector is read-only and never modifies your campaigns.

Why did my dashboard show 0 emails sent?

Q: Why did my open rate jump after the fix?

Open rate is opens divided by sends. While the Sent counter was wrong (showing 0 instead of the real number, say 50), the displayed open rate was 30 divided by 0 — which the dashboard rendered as 0% (the safe default for division by zero). After the fix, Sent shows the real value (50), and the formula returns the truthful 30 / 50 = 60% open rate. Your real open rate hasn't changed — only the displayed number has, because the denominator is now correct.

What this page is for

If you opened a finished email campaign on WarmySender between roughly May 5 and May 7, 2026, and the dashboard read "0 emails sent" while you could clearly see opens, replies, or bounces on the same card, this page is for you. Short version: the campaign DID send every email it was supposed to send. The "Sent" counter was reading from a temporary work queue that gets cleaned up after a campaign finishes, so once the cleanup ran, the counter could no longer find the source data and showed zero — even though the permanent record of every send was still on file. We fixed this on May 7, 2026 by changing the counter to read from the permanent record first and use the temporary queue only as a backup. Your numbers are accurate now.

WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. This page is part of the Cold Emailing pillar but applies to any campaign with email steps (including the email side of multichannel sequences).

What you saw on the dashboard

The contradiction looked like this on the campaign card:

Sent: 0
Opened: 30 (or whatever the real open count was)
Replied: 4
Open rate: 0% (calculated as 30 ÷ 0 → division by zero, displayed as 0%)

Your inbox almost certainly had the actual replies. The prospects' inboxes had the actual opens. The campaign had truly fired. The number that was wrong was the one in the top-left of the card — the "Sent" total — because it was reading from the wrong place once the campaign finished.

This was real. We fixed it. And we want to be transparent about what was happening so you understand exactly what the platform was doing under the hood.

What was happening behind the scenes

WarmySender records each email send in two places at the moment it goes out:

A permanent event row in our analytics database. This row exists forever — every send is logged here as it happens, and these rows are how we calculate opens, clicks, replies, bounces, and unsubscribes downstream.
A temporary queue row that the worker uses to track the in-flight job (the equivalent of "this email is being sent right now, expect a delivery confirmation in a moment"). These rows get cleaned up automatically once the work is done — they're a workspace, not a record.

The bug was that the dashboard's "Sent" counter was being recalculated periodically (every 10 minutes) by reading from the temporary queue rows ONLY. Once the cleanup process ran on a finished campaign — typically a day or two after the last email went out — those temporary rows were gone. The counter found zero rows, wrote zero into the dashboard, and the "0 emails sent" reading appeared.

Meanwhile, the permanent event rows were still right where they always are, holding the truthful count of what was sent. The other counters that read from the permanent rows (opens, replies, bounces) stayed correct. That's why the contradiction looked the way it did.

What we fixed on May 7, 2026

We changed the dashboard's "Sent" counter to read from the permanent event rows FIRST and fall back to the temporary queue rows only as a backup for the brief window before a permanent row commits. The new rule is simple: take the larger of the two counts. If the permanent rows say 50 sends and the temporary queue says 0 (because cleanup already ran), the counter writes 50. If a campaign just fired its first send and the permanent row hasn't committed yet, but the temporary queue says 1, the counter writes 1. The counter never falls behind reality.

The change is database-side only. Zero new email sends, zero new SMTP calls, zero changes to your campaigns or prospects. The fix landed in production on May 7, 2026, and the counter heals itself within one refresh cycle (10 minutes) on every affected campaign. We also ran a one-shot heal pass at deploy time so all 188 campaigns whose counters were stale at the moment of the fix were corrected immediately rather than waiting 10 minutes.

To make sure this can never silently come back, we shipped two complementary safeguards alongside the fix:

An automatic regression test. The test seeds a fake completed campaign with a permanent record but no temporary queue rows (simulating the post-cleanup state) and asserts that the refresher writes the correct count. Any future change to the counter logic that would re-introduce the bug will fail this test in our build pipeline before it can ship.
A continuous drift detector. A background job runs every hour, scans every email and multichannel campaign across the platform, and flags any campaign whose stored "Sent" counter is more than 5 emails below the real count from the permanent record. If even one campaign trips the threshold, an internal alert fires for our team. The detector is read-only — it never modifies your campaigns, just watches for the symptom. So even if a future regression slips past the test, the detector catches it within an hour.

How to verify your numbers are correct today

Three easy checks, in order of confidence:

Hard-refresh the dashboard. The campaign cards cache the rendered counters for 60 seconds. Hard-refresh once (Cmd-Shift-R on Mac, Ctrl-Shift-R on Windows) so you're seeing the post-fix value.
Check the prospect list view. Open the affected campaign and switch to the per-prospect list. Each row that shows a "Sent" timestamp is a confirmed send — count them, or sort by Sent date and use the row count at the bottom. This is the ground-truth count against which the dashboard tile is now reconciled.
Cross-check against your sender mailbox's Sent folder. The actual messages are in your mailbox's outbox/sent folder (Gmail, Outlook, iCloud, etc.) — every WarmySender send is also a real message in your sender's mailbox. If the count there matches the dashboard's new "Sent" counter, you're solid.

If the three numbers all agree, the fix is working as intended for your campaign. If they disagree by more than 5 — wait 10 minutes for the next refresh cycle, hard-refresh once more, and re-check. If they still disagree, contact support at hello@warmysender.com with the campaign name and a screenshot of the current counter, and we'll cross-check the underlying records for your specific campaign.

Common questions

Did I lose any sends? Do I need to re-run my campaign?

No, on both counts. The bug was a display issue, not a delivery issue. Every email that the dashboard said had been sent had really been sent. Every email that the dashboard counter "lost" had also really been sent — the bug only affected the count, never the underlying delivery. Your prospects received exactly the messages your campaign sent them, your opens and replies are real, and you don't need to re-import or re-launch anything. The fix simply updates the dashboard to show the truthful number.

Will this affect my email account safety, deliverability, or warmup?

No. The fix is database-only — zero new email sends, zero new SMTP authentication calls, zero changes to your sending pace, daily limits, or warmup schedule. Your sender's reputation is exactly where it was before the fix. The 4-week warmup ramp on new mailboxes is unchanged. Per-account daily and per-domain volume caps are unchanged. The fix only changes how we COUNT what's already been sent on the dashboard — it doesn't change anything about future sending.

Why did my open rate jump after the fix?

Open rate is calculated as opens divided by sends. While the "Sent" counter was wrong (showing 0 instead of the real number, say 50), the displayed open rate was 30 ÷ 0, which the dashboard rendered as 0% (you can't divide by zero, so the formula returned the safe default). After the fix, "Sent" shows the real value (50), and the formula returns the truthful 30 ÷ 50 = 60% open rate. Your real open rate hasn't changed — only the displayed number has, because the denominator is now correct. This is the truthful number going forward.

How do I know this won't happen again?

Two layers of protection. The first is an automatic regression test in our build pipeline that seeds the exact bug scenario (a finished campaign with permanent records but no temporary queue rows) and asserts the counter reads correctly. Any code change that would re-introduce the bug fails the test before it can ship to production. The second is a continuous drift detector — a background job that scans every email and multichannel campaign every hour and flags any campaign whose dashboard counter is more than 5 sends below the real count. If even one campaign trips the threshold, our internal monitoring fires an alert. The detector never modifies your campaigns; it just watches for the symptom. So the fix is protected at both the build-time and runtime layers.

What should I do if my dashboard still shows the wrong number?

Do these three things, in order: (1) Hard-refresh the page (Cmd-Shift-R on Mac, Ctrl-Shift-R on Windows) to bypass the 60-second display cache. (2) Wait 10 minutes for the next refresh cycle and hard-refresh once more — the counter recalculates from the permanent record on every cycle. (3) If after those two steps the dashboard still disagrees with what you see in the prospect list view OR your sender mailbox's Sent folder, contact support at hello@warmysender.com with the campaign name and a screenshot. We'll cross-check the underlying records and either confirm the dashboard is right (and explain the gap) or confirm a new edge case we haven't seen yet (and fix it).

Account safety

Zero new email sends, SMTP calls, or rate-limit risk. Every part of the May 7 fix runs against our database — recomputing the dashboard counter from the permanent record. We don't re-send any messages, don't re-authenticate any mailboxes, and don't bump any rate-limit budgets. The continuous drift detector is also read-only: it scans the database, writes an internal alert row if it finds drift, and never touches your campaigns or your mailboxes. Your sender reputation, deliverability, warmup ramp, and per-account daily caps are all preserved exactly as you configured them.

For the LinkedIn side of multichannel campaigns, none of the LinkedIn counters were affected by this bug — LinkedIn sends count from a different source that doesn't get cleaned up. The fix only touches the email "Sent" counter on email-only and multichannel campaigns. LinkedIn invites, accepts, replies, and connection rates were always correct.

Why was my LinkedIn InMail count corrected? — Sister explainer for the May 2 InMail counter fix. Same family of "dashboard shows the wrong number" issues, different counter and different root cause.
How WarmySender handles load — Architecture overview of the queue, the worker, and the periodic refresher that recalculates dashboard counters. Useful background for understanding what "permanent record vs temporary queue" actually means under the hood.
LinkedIn campaign documentation — How LinkedIn campaigns send, why acceptance rates can appear to lag, and what happens on disconnect.
Email Deliverability Hub — SPF, DKIM, DMARC, warmup, and inbox placement strategy. The 4-week warmup ramp and the per-domain caps mentioned above are part of this.
Cold Email Hub — Multi-step sequences, A/B testing, conditional branching, and best-practice send schedules for the email pillar of the platform.
Full documentation — All 90+ guides covering email warmup, cold email campaigns, LinkedIn outreach, and multichannel sequences.
Support — How to get in touch.

Still seeing something off? Email hello@warmysender.com with your campaign name and a screenshot — we'll dig into the specific account and confirm the numbers.