Is LogRocket Down?

No — LogRocket is up

Reachable from all 8 checked regions

Average response time: 247ms

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

146ms

Avg response, 30 days

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

30-day history

33-day clean streak

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

818ms

DNS 33ms TCP 2ms TLS 11ms TTFB 810ms

arn

254ms

DNS 106ms TCP 1ms TLS 8ms TTFB 248ms

bom

119ms

DNS 15ms TCP 2ms TLS 10ms TTFB 111ms

cdg

139ms

DNS 24ms TCP 2ms TLS 8ms TTFB 131ms

dfw

157ms

DNS 39ms TCP 2ms TLS 11ms TTFB 147ms

ewr

162ms

DNS 65ms TCP 2ms TLS 15ms TTFB 153ms

fra

182ms

DNS 73ms TCP 6ms TLS 10ms TTFB 176ms

yyz

148ms

DNS 34ms TCP 1ms TLS 6ms TTFB 137ms

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

Start Free Monitoring

Free plan available No credit card required