My LinkedIn replies aren't showing on the dashboard — what's happening?
If your dashboard is missing recent LinkedIn replies even though prospects are clearly replying on LinkedIn, the most likely cause is an upstream webhook outage at our integration partner our LinkedIn provider.
First, the important thing: every reply is still safely in your LinkedIn inbox — nothing is lost on LinkedIn's side. The gap is purely between our LinkedIn provider and WarmySender, NOT between you and your prospect.
How the signal flows:
Prospect replies on LinkedIn → LinkedIn delivers to our LinkedIn provider → our LinkedIn provider webhook (linkedin.reply_received) → WarmySender stamps the reply on your dashboard.
When our LinkedIn provider's webhook delivery stalls, the inbound message still reaches our database via a 30-minute polling fallback, but the platform-side side-effects that the webhook normally triggers (the linkedin_replied_at stamp on your prospect, the auto-stop-on-reply check, the Slack/n8n/Zapier reply notification, and the dashboard reply counter) only fire when the webhook handler runs. So during the outage you may see follow-ups continue on threads where the prospect has already replied.
Difference between platform-side and our LinkedIn provider-side:
- Platform-side (under our control) — DB writes for state-flip, dashboard counters, Slack/n8n/Zapier emit, auto-stop-on-reply. We have a 15-minute health monitor (Apr 30, 2026 Layer F1) that detects when webhook freshness drops below threshold and inserts a webhook_outage admin alert with kind='linkedin_reply_received_outage_suspected'.
- our LinkedIn provider-side (their job to fix) — actual webhook delivery from LinkedIn through to our /webhooks endpoint. When our LinkedIn provider's delivery stalls, our operator pages our LinkedIn provider support via their support channel.
What WarmySender does during the outage:
- The 15-minute webhook health monitor fires a critical-severity admin alert within one tick of the outage starting.
- The 30-minute polling fallback (syncAccountConversations in the LinkedIn scheduler) pulls inbound rows from our LinkedIn provider via LIST and writes them into linkedin_messages — so we keep a complete record of what arrived. This is bridging cover, not a fix.
- Once our LinkedIn provider restores webhook delivery, an operator runs an idempotent replay backfill that walks every inbound row that landed since the outage start and re-drives the missed state-flips through the canonical markProspectReplied helper. This retroactively stamps linkedin_replied_at on your prospects, fires the auto-stop-on-reply check, wakes any parked wait_reply or condition_linkedin_replied steps, and emits the missed Slack/n8n/Zapier notifications. The replay is idempotent — running it multiple times is safe.
What you can do as a customer:
- Reassurance: replies are not lost. Open the actual LinkedIn inbox to read them while waiting.
- If you have time-sensitive threads, manually pause the affected campaigns until the dashboard catches up — this prevents follow-ups from going out on already-replied threads during the outage window.
- Once recovery completes (typically within 1 hour of our LinkedIn provider fix + replay run), your dashboard reply counters will reflect ground truth and stop-on-reply will have been retroactively applied.
- If you suspect this is happening to your workspace, contact support at [email protected] with a sample prospect URL and approximate reply timestamp; we can verify the per-account state and confirm the recovery timeline.
No our LinkedIn provider API calls are made from the F1 detection or replay layer — account safety always wins. The platform's job during a webhook outage is detection + bridging via the polling fallback + replay on recovery; our LinkedIn provider-side fix is the operator's responsibility per the runbook.