Why does my InMail counter show different from my actual sends?

What this page is for

If you check your dashboard and see a daily InMail counter that doesn't match the actual number of InMails landed in your LinkedIn outbox, this page explains exactly what's going on. Short version: WarmySender keeps two numbers — a per-account daily counter (used to enforce LinkedIn's daily safe band) and an event log (the truth about what was actually delivered). They should agree. When they don't, our reconciler heals the gap and, if the gap looks dangerous, automatically pauses the account to protect it from LinkedIn-side throttling.

WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. This page is part of the LinkedIn Outreach pillar.

The two numbers, in plain language

The daily counter (cap-enforcement number)

Every connected LinkedIn account has a daily InMail counter, stored as inmails_sent_today on our side. It's incremented BEFORE we call LinkedIn's API — not after. We do this on purpose: pre-emptive incrementing prevents two things from happening simultaneously and racing past the daily safe band. The counter is what our cap-gate consults when deciding whether to allow the next InMail attempt. It's specifically designed to be "loud" — if anything goes wrong, the cap-gate errs on the side of pausing.

The counter resets to 0 at midnight UTC. That's a hard rule — every connected account's counter, day-marker, and ramp tracker all reset together in a single atomic database write, so no observer can ever see a half-reset state. (We hardened this on May 7, 2026 — see the May 7 fix section below.)

The event log (delivered-truth number)

Independently of the counter, every actually-delivered InMail produces an inmail_sent row in our event log. The event log is what the dashboard reads when displaying stats. It's also what feeds analytics, FAQ insights, and the "actual delivered" charts.

A delivered InMail returns a chat reference (a chat_id) from LinkedIn. On May 2, 2026 we introduced a chatId-required invariant — see Why was my LinkedIn InMail count corrected? — so every event row in the log has cryptographic proof of delivery on the LinkedIn side.

Why the two numbers can briefly differ

Three normal reasons:

  1. In-flight calls. If we just incremented the counter and the LinkedIn API call hasn't returned yet, the counter is +1 ahead of the event log for a few seconds. That's the design — we have to reserve the slot before we burn it. Within a minute or so, the event log catches up.
  2. API failures with rollback. Sometimes a LinkedIn-side error means the InMail wasn't delivered. In those cases we roll back the counter (decrement it). The event log was never written. Net effect: counter and events both at the same number, but for a few seconds during rollback they could differ by 1.
  3. Reconciler tick lag. Our drift reconciler runs every 10 minutes and corrects any small leftover divergence. So a window of up to ~10 minutes of small drift is normal between reconciler ticks.

What's not normal: a counter that's significantly larger than the event log (e.g. counter says 100, events say 17). That kind of gap means something went wrong with the increment-vs-rollback bookkeeping, not with the actual sends. The counter is wrong; the event log is right.

How we heal divergence automatically

Two layers of protection, both running every 10 minutes against every connected LinkedIn account:

Layer 1 — operation-side reconciler

The first reconciler reads the operation-side journals (the records of which sends our worker process actually attempted) and reconciles the counter against them. If the counter is too high relative to in-flight + completed work, it's lowered. If it's too low, it's raised. The reconciler can never lower the counter below the still-in-flight reservation count — that floor exists to prevent two concurrent workers from re-claiming the same slot during heal.

Layer 2 — event-grounded audit (new on May 7, 2026)

The new audit compares inmails_sent_today directly against the count of inmail_sent events for today. If the counter is more than 5 ahead of the event log, an alert is raised for our team to investigate. If the counter is more than 20% over the daily cap (e.g. 60 against a 50-cap), the account is automatically placed in a 1-hour cooldown — the same kind of cooldown LinkedIn applies during throttle windows. This is purely self-protective: even if the counter is wrong, the cooldown is benign for a real low-volume account, and life-saving for an account that's actually mid-blow-out.

Why we err so hard on the safe side

LinkedIn doesn't publish exact rate limits — they publish ranges and they enforce them at the account level with no warning. A Sales Navigator account's daily InMail safe band is around 50 InMails per day. Sustained sends above the band increase the chance of an account-level restriction, which can be unrecoverable.

Per CLAUDE.md "LinkedIn account safety always wins" — we will always pause an account too aggressively rather than let it overshoot. A paused account un-pauses tomorrow. A banned account is gone forever. So our reconciler is conservative on purpose, and our daily cap defaults are at or below the published safe band on every tier (free: 0 InMails, premium: 25, Sales Navigator: 50, Recruiter: 50).

The May 7, 2026 hardening

On May 7 we shipped three improvements specifically to this counter-vs-events relationship:

Common questions

My dashboard says I sent 17 InMails today but the daily cap shows 104/50 — what does that mean?

It means the counter and the event log diverged. Our drift reconciler will heal the gap within 10 minutes and, if the divergence is over 20% over your cap, will automatically place your account in a 1-hour cooldown to protect it. You don't need to do anything — the system is self-correcting. If the cooldown extends past 1 hour, contact hello@warmysender.com and we'll investigate the underlying cause.

Will the auto-cooldown affect my campaign delivery?

Briefly, yes — for the duration of the cooldown (1 hour or less in most cases). All paused work resumes automatically when the cooldown clears. Your campaign sequences are unaffected; the prospects scheduled during the cooldown window simply shift to the next eligible send time, respecting your sending window and timezone exactly as configured.

Why don't you just trust the event log and ignore the counter?

Two reasons. First, we need the counter as an atomic gate at send time — checking the event log on every send would be a race condition (two parallel sends could both pass the check before either writes its event). Second, the counter reflects in-flight reservations that haven't yet completed. The event log is for completed deliveries. We need both numbers, and we need them to agree. The reconciler is what enforces agreement.

Will this affect my LinkedIn account safety?

The change makes your account safer. Every change in the V16 §3.3 deploy is database-only — zero new LinkedIn API calls, no LinkedIn rate-limit risk, no account flags. The new auto-cooldown actively reduces the risk of LinkedIn-side throttling by stopping the account before it can overshoot. Account safety always wins over throughput. A banned LinkedIn account is unrecoverable, so we never run shortcuts that risk a flag.

What should I do if my counter still looks wrong after waiting 10 minutes?

Hard-refresh the dashboard once (counters are cached for ~60 seconds). If the counter still doesn't match, contact hello@warmysender.com with your campaign name, account name, and a screenshot of the dashboard. We'll cross-check the event log against the counter for that specific account and confirm whether the divergence is real or a stale cache.

Account safety

Zero new LinkedIn API calls. Every part of the May 7 fix runs against our database — annotating drift rows, updating cooldown timestamps, inserting alert rows. We don't re-poll LinkedIn to "verify" anything because re-polling at scale would risk tripping LinkedIn's automation detection and getting accounts restricted.

Per-account daily and weekly InMail caps, sending windows, and timezone scheduling are unchanged. The new event-grounded audit reads from the database only — it never calls LinkedIn. It writes a heartbeat row every run (whether or not it finds anything to alert on) so we can verify the reconciler is alive.

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