Skip to main content
Liveblocks logo

Is Liveblocks Down?

No — Liveblocks is up

Reachable from all 8 checked regions

Average response time: 783ms

Last checked · checks run every 6 hours

Official status page: https://liveblocks.statuspage.io

Liveblocks uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
731ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 13 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

13-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: 100.00% uptime, 35 checks
Sep 9: 100.00% uptime, 32 checks
Sep 10: 100.00% uptime, 32 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 31 checks
Sep 13: 100.00% uptime, 32 checks
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 31 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 16 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
1026ms
DNS 126ms TCP 2ms TLS 19ms TTFB 421ms
arn
878ms
DNS 72ms TCP 7ms TLS 12ms TTFB 370ms
bom
872ms
DNS 32ms TCP 2ms TLS 8ms TTFB 391ms
cdg
1101ms
DNS 162ms TCP 9ms TLS 19ms TTFB 954ms
dfw
376ms
DNS 80ms TCP 1ms TLS 55ms TTFB 307ms
ewr
433ms
DNS 47ms TCP 1ms TLS 22ms TTFB 250ms
fra
923ms
DNS 59ms TCP 1ms TLS 13ms TTFB 323ms
gru
658ms
DNS 14ms TCP 1ms TLS 7ms TTFB 482ms

What Liveblocks does

Liveblocks provides the infrastructure behind multiplayer features in web applications: presence indicators, live cursors, comments, notifications and conflict-free shared documents. Applications connect to it over WebSockets and it synchronises state between everyone in a room. Products that build collaborative editing on it depend on it for the parts users notice most immediately.

What an outage looks like

Collaborators disappear from a document, cursors and presence stop updating, and edits made by one person never appear for anyone else. Each user often keeps editing their own local copy without an error, so two people can both believe they are working normally while seeing entirely different content. Comments and notifications stop loading.

What to do about it

Read liveblocks.statuspage.io, which reports API and Website and Dashboard as its components. If API is affected, treat the session as unsynchronised rather than healthy and warn collaborators before they diverge further. Avoid having several people continue editing the same document during an incident, since the reconciliation on recovery is the part most likely to surprise you. If only Website and Dashboard is affected, your application's realtime connections are unaffected.

Is it down for everyone, or just you?

If this page says Liveblocks is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Figma
Figma
Miro
Miro
Notion
Notion
Ably
Ably

Liveblocks outage FAQ

My document still edits normally but nobody else sees my changes. Is Liveblocks down?
That is the characteristic symptom. Liveblocks clients apply changes locally first and synchronise them afterwards, so an interruption leaves each person editing a working local copy with no error shown. Everyone believes the document is fine and everyone is seeing something different. Check the API row on liveblocks.statuspage.io as soon as presence indicators or cursors stop moving, because that is the earliest visible sign.
Will edits made during a Liveblocks outage be lost?
Liveblocks uses conflict-free data structures designed to merge changes when a connection is restored, so edits made offline commonly reconcile rather than disappear. Liveblocks does not publish a guarantee covering every failure mode, so treat reconciliation as likely rather than certain, and copy anything irreplaceable out of the editor before refreshing. Refreshing mid-incident is the action most likely to discard unsynchronised local state.
Is it Liveblocks or my own WebSocket connection?
Compare scope. A local network or proxy blocking WebSockets affects one user, often on a corporate network or VPN, while a Liveblocks incident disconnects every collaborator at once. The measurements above probe from several regions, so if they all report the service reachable and only one person has dropped out, look at that person's network before the platform.
The Liveblocks dashboard will not load. Is my application affected?
Probably not. Liveblocks reports Website and Dashboard as a component separate from API, so the site you use to inspect rooms and usage can be down while your application's realtime connections continue normally. Treat it as lost administration rather than an outage, and check the API row to confirm end users are unaffected.
Should I tell users to stop editing during a Liveblocks incident?
For shared documents, yes, it is usually the safer instruction. The longer several people edit the same room while disconnected, the more divergent local states have to be merged on recovery, and the more likely someone sees an outcome they did not expect. Asking collaborators to pause and to copy anything critical elsewhere costs little and avoids the messiest failure mode.

How we measure this

  • We request Liveblocks's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Liveblocks publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Liveblocks goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required