Why does my LinkedIn UI sometimes lag behind reality?
Occasionally the WarmySender dashboard shows a status that doesn't match what you see on linkedin.com — a campaign tile says 'Connected · last activity 4h ago' but your LinkedIn shows a recent message; or your dashboard says an InMail was sent but your LinkedIn Sent folder doesn't show it yet. Here's why this can happen and what to do.
What WarmySender's status reflects
The platform reads two distinct timestamps for each LinkedIn account:
- last_sync_at — When Unipile last successfully checked your session. This advances on auth pings (every ~30 minutes) regardless of whether you sent anything.
- last activity / MAX(completed_at) — When your most recent send job actually completed. This is what the dashboard tile reads (LL#281 honesty fix). It only advances when a real send goes out.
When the two diverge — for example, your account just polled successfully (last_sync_at fresh) but no new sends have completed in the last few hours — the tile correctly shows the older 'last activity' timestamp. This isn't a bug; the dashboard is being honest about what's happening on LinkedIn versus what's happening at the auth layer.
Why webhook events can be delayed
LinkedIn → Unipile → WarmySender is a 3-hop chain. Most events arrive in under 10 seconds. Some can take longer:
- new_relation (acceptance) webhooks: typical < 5s, occasional minutes during LinkedIn graph propagation delays.
- message_received webhooks: typical < 10s, occasional minutes for messages from accounts in different LinkedIn data centers.
- account.status_changed webhooks: typical < 30s, but can be delayed up to several minutes after a credentials rotation.
When events are delayed, the dashboard catches up via the 30-minute polling fallback. Worst case, your dashboard is up-to-date within 30 minutes even if a specific webhook missed delivery.
Why you might get a 're-login needed' email when the UI shows 'Connected'
This specific symptom usually means one of two things:
1. The account-lifecycle webhook source missed an event and our DB-side health probe surfaced the issue from the polling fallback before the webhook arrived. The platform now runs a daily audit cron that watches for this exact gap (account.* webhook source delivering 0 events for 24h+) and auto-recovers the subscription if needed.
2. Your LinkedIn session genuinely needs to be re-authorized — the email is right, the UI is stale. Click Reconnect on the LinkedIn Accounts page; the next polling tick will refresh the UI.
What to do when you see a stale UI
1. Hard-refresh the dashboard (Cmd-Shift-R on Mac, Ctrl-Shift-R on Windows). The frontend caches data for 30s; a hard refresh forces a fresh fetch.
2. Check the LinkedIn Accounts page directly — it's the most authoritative status surface.
3. Wait 30 minutes. The polling fallback runs every ~30 minutes and reconciles any drift.
4. If the UI is still wrong after 30 minutes AND a hard refresh, contact support — we'll trace the specific event chain and identify the gap.
The dashboard never lies on purpose
Several honesty fixes have been shipped in the last few months: LL#247 (status pill semantics), LL#281 (last-activity tile derived from real send data, not auth pings), LL#256 (defer-not-burn for HTTP 422 surfaces), LL#275 (phantom-accept-reverted exclusion in stats). Each closes a gap where the dashboard could show a number that didn't match reality. Our standing rule: if the platform isn't sure of a value, the tile is empty or shows 'Unknown' — never a stale or made-up number.