I aligned on scope: Tinder = dating app with swipe-based matching; we’re investigating a 12% sudden drop in successful logins last month (accelerating daily). Focus is absolute login count, not rate.
Metric sanity: “Successful login” = user completes auth and lands in-app. No definition or analytics pipeline changes. Pattern: global, all platforms (iOS/Android/Web), first-time and re-login flows affected; already-logged-in users are fine. That points to auth entry points, not session retention.
I ruled out quick externals: no regulatory or PR shocks; however, other apps (e.g., Spotify) also reported login failures in the same window. That suggested a shared dependency rather than a Tinder-only bug.
I mapped the login funnel and auth methods:
Phone/OTP → working
Email code → working
Login with Facebook (SDK) → failing (primary impact)
Social (Google/Apple) → healthy
Engineering confirmed no auth-flow changes on our side; issue onset correlates with a recent Facebook Login SDK update. Users trying Facebook SSO hit errors; once they log out or reinstall, they can’t get back in via FB SSO. This explains the sudden cliff, global blast radius, and cross-industry effect.
RCA (succinct): Logins ↓ because Facebook SSO attempts fail; Facebook SDK update introduced a breaking change; Tinder’s dependency on FB SSO for a large share of new/re-logins amplified impact.
Immediate actions (0–72 hours):
Fail-open UX: Gray out “Continue with Facebook” + tooltip (“Temporarily unavailable—use phone/email instead”). Deep-link to alt methods.
Smart reroute: Auto-detect FB errors → show one-tap OTP to the phone on file (where consent exists) or fast email code.
Session protection: Extend session TTL and relax forced re-auth to avoid logging users out during incident.
Comms: In-app banner, status page, and social updates (“Facebook Login outage—use phone/email meanwhile”).
Telemetry: Add explicit auth-source tagging and error-classification for every attempt to isolate blast radius.
Follow-ups (1–3 weeks):
SDK mitigation: Pin to last-known-good FB SDK or hotfix via feature flag; ship circuit breaker that auto-disables FB SSO if error rate > threshold.
Resilience: Broaden multi-id linking (phone + email + Google/Apple) so users can recover accounts if one IdP fails; build self-serve account linking flow.
Observability: Auth funnel dashboards (per IdP) with alerting on: attempt volume, error codes, step latency, success rate by version/region.
Chaos tests: Staged IdP outage drills in lower envs to verify fallbacks and UX copy.
Longer-term hardening (4–12 weeks):
Progressive auth: Try silent token refresh → fallback to alt SSO → fallback to OTP, in one path, with minimal friction.
Passwordless by default: Default to phone/email magic-link for new users; offer SSO as an optional accelerator, not a single point of failure.
Risk-based auth: If device, IP, and behavior look safe, allow fast re-entry with biometrics/MPIN even when IdP is degraded.
How I’d measure recovery:
North Star: Daily successful logins back to (and above) pre-incident baseline.
Leading indicators: Share of logins by method (FB share ↓ during incident, alt methods ↑), FB SSO error rate ↓, time-to-login (p50/p95) ↓.
Quality checks: Account lockouts ↓, help-center tickets about login ↓, re-login success for previously failing FB users ↑.
One-liner summary I’d give in the room: This is a third-party IdP (Facebook Login) regression causing global SSO failures; we’ll de-emphasize FB SSO in real time, auto-reroute users to passwordless OTP/email, pin or roll back the SDK, and harden the auth stack so a single IdP can’t take logins down again.