01 — Foundation

Offline is a state, not a surprise

When connectivity drops, users need honesty about what still works and what is queued.

Offline and flaky-network states appear in mobile apps, trains, rural connections, and corporate VPNs. Pretending everything is fine — or showing a generic error with no path forward — breaks trust fast.

02 — Communicate

Tell users what offline means here

Be specific about read-only mode, queued actions, or full unavailability.

  • persistent but calm banner — “You’re offline. Changes will sync when you reconnect.”
  • distinguish “cannot load” from “can browse cached content”
  • show queued or pending actions with retry when back online
  • avoid blaming the user — “Check your connection” is fine; “You went offline” is not
<p role="status" aria-live="polite">
    You are offline. Edits are saved on this device and will upload when connection returns.
</p>

03 — Behaviour

What still works

Progressive enhancement: core reading and drafts may work; payments usually should not.

  • disable or defer actions that require the server — with clear reason
  • do not lose in-progress form data; persist locally where appropriate
  • sync conflicts after reconnect need the same care as multi-tab save conflicts
  • test flaky networks — not only aeroplane mode

04 — Detection

Detecting connectivity carefully

Browser online events are hints, not proof the API responds.

  • combine navigator.onLine with failed fetch handling — false positives happen
  • recover gracefully — dismiss banners and resume sync without duplicate submissions
  • idempotent retries for actions users may have tapped twice while offline

05 — Review

Before you approve

A short checklist for offline states in code review.

  • offline messaging is visible, specific, and non-accusatory
  • disabled actions are explained; queued work syncs safely on reconnect
  • errors and save failures cross-link with Error States and Save States patterns