Does the missing webhook channel affect my sending?

No. That webhook channel delivers lifecycle events (status changes); it does NOT carry actual send/receive traffic. The acceptance-signal channel and the reply-signal channel are what drive your campaign's real-time tracking — and both of those flow continuously and would be obvious if they broke. The missing lifecycle channel affects only our re-auth notifier accuracy, not your sending pipeline.

What if the upstream integration rate-limits the auto-resubscribe?

If the upstream returns a rate-limit response, we do NOT retry. A critical internal alert is fired and our ops team investigates manually. The 7-day rate-cap lock is consumed regardless (we set the lock BEFORE the call so a partial failure still consumes the window — the alternative is hammering the upstream, which is the LinkedIn-ban-risk pattern we always avoid). On day 8, if the alert is still open, the auto-resubscribe will try once more.

What's the long-term plan if the upstream drops the channel again?

Same daily audit + 2-day-persistence escalation + 7-day rate cap. The pattern is intentionally simple: detect, alert, attempt one fix, surface failures loudly. We don't add more retry cycles or shorter intervals because every upstream call carries a non-zero risk of contributing to a burst-throttle scenario. We will iterate on the threshold (currently 2 days) if production data shows a pattern that 2 days is too long, but the architectural shape stays the same.

Why am I still getting re-login emails when my LinkedIn account shows Connected?

Q: Is this related to the May 7 late-accept backfill?

Both are part of the same batch but address different observability gaps. The late-accept backfill catches prospects whose follow-up was stuck waiting on the rate-capped 6-hour heal-tick. The auto-resubscribe catches accounts whose webhook channel was silently dropped upstream. They share the same release window and the same principle (detection alerts paired with auto-remediation), but operate on different parts of the system.

Overview

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 and covers a subtle observability gap that can produce re-login emails (or Slack disconnect alerts) for an account that the dashboard correctly shows as Connected with recent activity.

If you've received a re-login email but your dashboard shows the account as healthy, this page explains what's happening, what we've fixed, and what to do.

The three LinkedIn webhook sources

WarmySender registers three webhook sources at boot with our LinkedIn integration:

Connections — delivers events when someone accepts your LinkedIn invite. This drives the dashboard "Sent today" counter, the late-accept matcher, and the auto-fire follow-up dispatcher.
Messaging — delivers inbound message events when someone replies to your campaign. This drives the inbox, the reply notifier, and the workflow's stop-on-reply behavior.
Account lifecycle — delivers account-lifecycle events (status changed, restricted, reconnected) for your LinkedIn account. This drives our re-auth notifier email and Slack disconnect/restrict alerts. This is the source that produces the symptom on this page when it goes dark.

The Connections and Messaging sources flow continuously and are easy to spot if they break (your dashboard goes silent in a way you'd notice). The Account lifecycle source is harder — it only fires on lifecycle changes, so a healthy connected account produces zero events for days at a time. If the account lifecycle source silently drops on the LinkedIn-integration side, our re-auth notifier loses its ground truth: it now reads stale state from a health probe instead of from the live webhook stream, which can produce false-positive re-login emails.

The symptom (Talha pattern)

The customer-visible symptom looks like this:

You receive an email saying "Please re-login to your LinkedIn account on WarmySender" (or you see a Slack alert from our integration).
You log into WarmySender → Settings → LinkedIn Accounts.
The dashboard shows your account as Connected. The "Last activity" tile shows a recent timestamp. Sends are flowing. Replies are flowing. Nothing on the dashboard suggests the account is in trouble.

You're in this state because our re-auth notifier was triggered by stale internal state (e.g., a token-rotation health probe that hadn't refreshed against the live source), but the source-of-truth (the account lifecycle webhook source) hasn't actually delivered any disconnect event. The dashboard's "Connected" status is correct; the re-login email is a false positive caused by the missing webhook source.

Our fixes — daily audit, alert, auto-resubscribe

Three layers protect against this pattern:

Daily audit (May 2, 2026). A scheduled job runs once per UTC day at 00:30 UTC and compares the registered webhook sources on the LinkedIn-integration side against the three we expect (Connections, Messaging, Account lifecycle). If the account-lifecycle source is missing, an internal alert is raised for our ops team.
One-shot auto-create. If the account-lifecycle source is missing AND we haven't attempted to create it in the last 7 days, the audit makes ONE call to register the source. This is rate-capped at 1 call per 7 days regardless of audit findings — we never blanket-recreate webhook subscriptions because that pattern has tripped integration-side rate limits in past incidents.
2-day persistence escalation (May 7, 2026). If the missing-source alert has been firing for 2 consecutive UTC days (a signal that the daily audit's auto-create either failed silently or hasn't landed on the integration side yet), an ADDITIONAL one-shot register call is attempted, gated by a distributed lock with a 7-day lifetime. The lock guarantees at most one register call per 7-day window even if the function is invoked multiple times. On rate-limited responses, no retry; we surface a critical webhook-outage alert for ops review.

Why the 7-day rate cap?

The "always prioritize account safety" rule applies here as much as it does to message dispatch: repeated failed LinkedIn-integration calls are a LinkedIn-ban-risk signal regardless of what the call is actually doing. Past incidents showed that blanket-recreating webhook subscriptions on every "missing source" detection can multiply a single dropped subscription into many calls per minute, which trips the platform-level safety mode. Once that safety mode is tripped, NO LinkedIn-integration calls land — for any account on the platform — until manual intervention.

The 7-day cap is conservative on purpose. Even if the account-lifecycle source is dropped ten times in one day on the integration side, we attempt to recreate it at most once. If our recreation attempt itself fails (network error, transient integration outage), we wait 7 days before trying again. The cost of waiting 7 days is a few extra false-positive re-login emails for affected customers; the cost of retrying aggressively is platform-wide outage. We always pick the first.

What you see when the fix lands

If you've been receiving false-positive re-login emails and your dashboard shows the account as Connected, the auto-resubscribe path will catch up within 1–2 daily audit cycles after deploy:

Day 0 (audit fires): if the account-lifecycle source is missing, an internal alert is created; one auto-recreate attempt fires (rate-capped per 7d).
Day 1 (audit fires again): if alert still open AND auto-recreate hasn't landed, the escalation fires the second auto-recreate (gated by the 7-day distributed lock).
Day 1+ (next account-lifecycle event): the recreated source delivers the next status event (e.g., your account's next reconnect, restriction, or status change). Our internal health probe gets a fresh data point. The re-auth notifier stops false-firing.

You will NOT see:

A flood of re-auth attempts — the 7-day distributed lock blocks any duplicate calls.
An interruption to your existing campaigns. The webhook sources are observability-only — if all three were temporarily down, your sending wouldn't stop, only your real-time accept and reply tracking would.
Any change to your LinkedIn account's connected state. The auto-resubscribe is purely a server-side configuration fix; it doesn't touch your LinkedIn session, token, or cookies.

What to do now if you got a re-login email

Three-step verification:

Check the dashboard. Open Settings → LinkedIn Accounts. If the row shows Connected with a recent "Last activity" timestamp (within the last few hours during your sending window), the email is most likely a false positive caused by this pattern.
Check your sending. Open the campaign list. If sends are flowing today (the "Sent today" counter is incrementing as expected), your account is genuinely healthy. The re-login email is a false positive.
If both check out, ignore the email. Don't click "Re-login" — re-logging would trigger an unnecessary token rotation and could reset some short-lived ramp progress. The auto-resubscribe will heal the underlying observability gap within 1–2 days.

If sends are NOT flowing AND the dashboard shows Connected, that's a different pattern — probably a webhook subscription continuity gap on reconnect, OR a genuine token-rotation issue. In that case, follow the re-login flow as instructed and contact hello@warmysender.com with your workspace name so we can investigate.

Account safety — one LinkedIn-integration call per 7 days

The auto-resubscribe is the ONE LinkedIn-integration call this fix introduces, and it's strictly capped:

1 register call per 7-day window, gated by a distributed lock. No retry on rate-limited responses.
0 extra reads added. The 2-day persistence signal comes from our internal alert count — no additional probing on the LinkedIn-integration side.
Cannot trip the platform-level safety mode. One call per 7 days is far below any meaningful threshold; a banned LinkedIn account is unrecoverable, so we always err on the side of cautious rate-limiting.
Surfaces failures loudly. On rate-limited responses, a critical internal webhook-outage alert is fired for ops review. We don't silently swallow.

This is the "detection-paired-with-auto-remediation" discipline: every detection alert in our infrastructure either has a paired auto-remediation OR a clearly-defined operator-action playbook. Silent detection that requires manual intervention burns customer trust the longer it persists, so we close the loop with auto-remediation wherever the action is bounded enough to be safe.

Common questions

My account shows Connected and sending is flowing, but I got a re-login email. Did I lose any sends?

No. The re-login email is a false positive — your account is genuinely healthy. The email was triggered by stale internal state from the missing account-lifecycle webhook source, but no actual disconnect happened. Your campaigns continued sending, your sends landed, and your reply tracking is real. The fix heals the observability gap within 1–2 days; you don't need to take any action.

Should I click "Re-login" anyway just to be safe?

No, please don't. Re-logging unnecessarily triggers a token rotation, which can interrupt the warmup ramp progress on a fresh account and adds load to the LinkedIn-integration's session-management system. If your dashboard shows Connected with recent activity, the connection is healthy. Wait 1–2 days for the auto-resubscribe to heal the source.

Does the missing account source affect my sending?

No. The account-lifecycle source delivers status-change events; it does NOT carry actual send/receive traffic. The Connections source (acceptance signals) and Messaging source (reply signals) are what drive your campaign's real-time tracking — and both of those flow continuously and would be obvious if they broke. The missing account-lifecycle source affects only our re-auth notifier accuracy, not your sending pipeline.

How can I tell if the auto-resubscribe has landed?

Email hello@warmysender.com with your workspace name and we'll check the internal audit log. The auto-resubscribe records each attempt and its outcome (success, rate-limited, or error) — our support team can confirm exactly when your case healed.

What if the LinkedIn integration rate-limits the auto-resubscribe?

If the integration returns a rate-limit response, we do NOT retry. A critical internal webhook-outage alert is fired and our ops team investigates manually. The 7-day lock is consumed regardless (we set the lock BEFORE the register call so a partial failure still consumes the window — the alternative is hammering the integration, which is the LinkedIn-ban-risk pattern we always avoid). On day 8, if the alert is still open, the auto-resubscribe will try once more.

Why do you wait 2 days before escalating instead of fixing it the same day?

Because the daily audit already attempts one auto-create on day 0 when it detects the missing source. The escalation fires on day 2+ specifically to catch the case where the day-0 attempt either failed silently OR the registration landed on the integration side but the customer-facing alert hadn't yet been ack'd. Two days of persistence is a strong signal that something is genuinely stuck and worth a second attempt. Escalating same-day would risk piling repeat calls on a transient integration outage — which is exactly the platform-wide safety-mode pattern the rate cap exists to prevent.

Is this related to the May 7 late-accept backfill?

Both are part of the same May 2026 batch but address different observability gaps. The late-accept backfill catches prospects whose follow-up was stuck waiting on the rate-capped 6-hour heal-tick. The auto-resubscribe catches accounts whose account-lifecycle webhook source was silently dropped on the LinkedIn-integration side. They share the same release window and the same principle (detection alerts paired with auto-remediation), but operate on different infrastructure.

What's the long-term plan if the source is dropped again?

Same daily audit + 2-day-persistence escalation + 7-day rate cap. The pattern is intentionally simple: detect, alert, attempt one fix, surface failures loudly. We don't add more retry cycles or shorter intervals because every LinkedIn-integration call carries a non-zero risk of contributing to a platform-wide safety-mode trip, and the cost of a few extra false-positive re-login emails is dramatically lower than the cost of a platform-wide rate-limit incident. We will iterate on the threshold (currently 2 days) if production data shows a pattern that 2 days is too long, but the architectural shape stays the same.

Late-accept follow-up: auto-fire, heal-tick backstop, and the May 7 historical backfill — Late-accept backfill explainer
Why did my LinkedIn account disconnect — and how to reconnect — Token rotation, 4-step reconnect flow
Why isn't my LinkedIn campaign sending? — Seven common patterns including reconnect 23514, future-NSA, webhook reconnect
Why does my account show Connected but no sending? — Last-activity tile + counter-drift reconciler
How WarmySender handles load — Queue architecture + recurring heals + cache-layer best practices
Full documentation — All guides
Support — How to get in touch

If you've received a re-login email and your dashboard shows the account as Connected, email hello@warmysender.com with your workspace name and we'll confirm the auto-resubscribe path is healing your case.