Is LogRocket Down?

No — LogRocket is up

Reachable from all 8 checked regions

Average response time: 233ms

Last checked 2 hours ago · checks run every 6 hours

Official status page: https://status.logrocket.com

LogRocket uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

195ms

Avg response, 30 days

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

30-day history

52-day clean streak

Sep 10 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.

jnb

299ms

DNS 187ms TCP 0ms TLS 10ms TTFB 297ms

lax

146ms

DNS 75ms TCP 1ms TLS 11ms TTFB 142ms

lhr

161ms

DNS 19ms TCP 2ms TLS 13ms TTFB 156ms

nrt

474ms

DNS 395ms TCP 1ms TLS 10ms TTFB 472ms

ord

183ms

DNS 54ms TCP 1ms TLS 11ms TTFB 179ms

sin

181ms

DNS 72ms TCP 1ms TLS 7ms TTFB 177ms

sjc

190ms

DNS 76ms TCP 3ms TLS 10ms TTFB 184ms

syd

235ms

DNS 136ms TCP 1ms TLS 7ms TTFB 232ms

What LogRocket does

LogRocket records what users actually did in a web or mobile application: session replay paired with console logs, network requests and errors, plus product analytics and alerting. Engineering and support teams use it to reproduce a bug from the user's side rather than from a stack trace alone, and to see where people abandon a flow.

What an outage looks like

The dashboard fails to load, or sessions stop appearing so recent activity looks like a drop in traffic. Session collection problems mean recordings for that window never arrive and cannot be recovered later. Timeline and Issues views fail to open replays. Alerts stop firing, and the Slack, GitHub and Intercom integrations stop posting. Login through the authentication provider may fail.

What to do about it

status.logrocket.com separates Session Collection from the Dashboard, Timeline, Issues, Metrics, Alerts, Streaming Data Export, the integrations and authentication. Collection is the one that matters most: sessions missed during an incident are gone, so note the window and avoid drawing conclusions from it afterwards. If Alerts is degraded, watch your other error monitoring rather than reading quiet as healthy.

Is it down for everyone, or just you?

If this page says LogRocket 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

LogRocket outage FAQ

Our session count dropped. Did traffic fall?

Check Session Collection before acting on it. That component is separate from the dashboard, and when it is degraded sessions are not recorded even though users are still on the site. Traffic looks like it collapsed when only the recording did. Compare against your server logs or another analytics source for the same window before reporting a drop to anyone.

Can we recover sessions from the outage window?

No. Session replay depends on data captured at the time, so recordings that were never collected cannot be rebuilt afterwards. Note the start and end of the incident and treat that window as missing rather than empty in later analysis. Bugs reported by users during it need reproducing from their description instead of from a replay.

Alerts went quiet. Is our application healthy?

Do not assume so. Alerts is its own component and can stop firing while the application has real problems, which makes silence during a LogRocket incident uninformative. Fall back to your other error monitoring or uptime checks for that period, and re-examine the window once alerting recovers rather than treating the gap as a clean run.

Is LogRocket down or is our snippet broken?

Compare across users and environments. If no sessions arrive from anywhere and the status page shows Session Collection degraded, it is upstream. If sessions arrive from some builds and not others, look at your recent deploys, the initialisation call, and whether a content security policy or blocker is stopping the script loading for those users.

How we measure this

We request LogRocket'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 LogRocket 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 LogRocket 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