Skip to main content
Liveblocks logo

Is Liveblocks Down?

No — Liveblocks is up

Reachable from all 8 checked regions

Average response time: 803ms

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
782ms
Avg response, 30 days

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

30-day history

34-day clean streak
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, 32 checks
Sep 21: 100.00% uptime, 32 checks
Sep 22: 100.00% uptime, 32 checks
Sep 23: 100.00% uptime, 32 checks
Sep 24: 100.00% uptime, 38 checks
Sep 25: 100.00% uptime, 32 checks
Sep 26: 100.00% uptime, 32 checks
Sep 27: 100.00% uptime, 32 checks
Sep 28: 100.00% uptime, 32 checks
Sep 29: 100.00% uptime, 31 checks
Sep 30: 100.00% uptime, 32 checks
Oct 1: 100.00% uptime, 32 checks
Oct 2: 100.00% uptime, 32 checks
Oct 3: 100.00% uptime, 32 checks
Oct 4: 100.00% uptime, 32 checks
Oct 5: 100.00% uptime, 32 checks
Oct 6: 100.00% uptime, 32 checks
Oct 7: 100.00% uptime, 32 checks
Oct 8: 100.00% uptime, 32 checks
Oct 9: 100.00% uptime, 32 checks
Oct 10: 100.00% uptime, 32 checks
Oct 11: 100.00% uptime, 32 checks
Oct 12: no data
Sep 13 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
763ms
DNS 13ms TCP 2ms TLS 23ms TTFB 313ms
arn
1046ms
DNS 157ms TCP 1ms TLS 10ms TTFB 541ms
cdg
817ms
DNS 115ms TCP 9ms TLS 19ms TTFB 392ms
dfw
655ms
DNS 171ms TCP 0ms TLS 53ms TTFB 624ms
sin
817ms
DNS 6ms TCP 1ms TLS 11ms TTFB 305ms
sjc
341ms
DNS 133ms TCP 1ms TLS 12ms TTFB 280ms
syd
831ms
DNS 155ms TCP 1ms TLS 7ms TTFB 415ms
yyz
1157ms
DNS 91ms TCP 11ms TLS 34ms TTFB 924ms

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 17 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 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required