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 Unipile.
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 Unipile and WarmySender, NOT between you and your prospect.
How the signal flows:
Prospect replies on LinkedIn → LinkedIn delivers to Unipile → Unipile webhook (linkedin.reply_received) → WarmySender stamps the reply on your dashboard.
When Unipile'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 Unipile-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'.
- Unipile-side (their job to fix) — actual webhook delivery from LinkedIn through to our /webhooks endpoint. When Unipile's delivery stalls, our operator pages Unipile 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 Unipile 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 Unipile 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 Unipile 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 Unipile 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; the Unipile-side fix is the operator's responsibility per the runbook.