How does WarmySender redistribute schedule when I disconnect?
When a LinkedIn account disconnects (LinkedIn rotated your session token, you triggered a 2FA prompt, or the account was paused for any reason) WarmySender holds your campaign schedule in place — but it doesn't burst-send the backlog the moment you reconnect. This guide explains how the platform redistributes prospect schedules to keep your account safe.
The core invariant: account safety always wins
LinkedIn's anti-abuse signal-set heavily weighs 'unusual burst activity after a quiet period' as a strong automation signal. A disconnect of any duration followed by an immediate flood of messages or invites looks indistinguishable from a botted-account pattern, regardless of whether the activity is real or automated. The platform's design constraint is: never burst after a reconnect, ever.
What happens during a disconnect
- Active send jobs that were 'in flight' when the disconnect occurred get released atomically (status reset, processing lock cleared, paired campaign_send_jobs.run_at updated). This prevents stuck-in-processing rows from accumulating.
- Future-scheduled prospects whose next-action timestamp falls during the disconnect window are NOT immediately moved. They stay on their existing schedule.
- The campaign auto-pauses with reason='linkedin_account_disconnected' so it doesn't try to send while the account is dark.
What happens during a reconnect
- The account flips to status='connected' and webhook subscriptions re-register on Unipile's side.
- The auto-resume sweeper resumes campaigns paused for the disconnect within ~5 minutes.
- Prospects whose next-action timestamp passed during the disconnect get re-clamped forward to the next valid sending window using the canonical clampToSendingWindow helper. The clamp respects schedule_days, sending_window_start / sending_window_end, timezone, and randomize_within_window — exactly the same settings the campaign was authored with.
- A small random offset (0-30 minutes) is added per prospect during redistribution so prospects that would otherwise share a scheduled minute are spread out.
Why this can sometimes look like 'all my prospects are scheduled for next Monday'
If your campaign's schedule_days are restrictive (e.g., [Monday, Thursday] only), and the disconnect spanned multiple weekdays, the next valid sending window for a large block of prospects might land on the same Monday. The platform's drift reconciler now skips imminent-valid-day rows (next-action within 24h AND on a valid weekday) so genuinely-correct schedules don't get re-distributed unnecessarily — but if your authored schedule is [Mon, Thu] and the drift cohort all land in the same Monday window, that's the schedule doing what you authored, not a bug.
If you ever see hundreds of prospects scheduled for the same single Monday and that's NOT what you intended, please email support — we shipped LL#293 specifically to address an over-shift pattern that produced this exact symptom platform-wide on May 2 2026, and the redistribute script is the canonical recovery tool.
The per-account ramp survives reconnects
Your 4-week LinkedIn safety ramp (10 invites/day → 50 invites + 150 messages/day) is per-account, not per-campaign, and it accumulates across disconnects. Reconnecting after a 24-hour disconnect doesn't 'reset' your ramp — you pick up from where you left off, slightly delayed. This is intentional: the ramp is what keeps your account safe.
Does the platform ever speed up after a reconnect?
Never. The platform always defers, never accelerates. If your dashboard shows a higher per-day cap than what's actually being sent, that's the daily cap (the upper bound) — not a target. Actual throughput respects the campaign's per-prospect timing, the account's ramp schedule, the per-account daily/weekly limits, and Unipile's per-account hourly burst limit. Each gate clamps independently. Worst case after a reconnect: a few rows are deferred slightly longer than they would have been if the account had stayed connected. Best case: the schedule catches up smoothly within the next few sending windows.