Troubleshooting

This page lists the most common issues seen with the browser SDK and how to debug them quickly.

Step 1: Confirm the SDK loaded

In your browser console:

typeof window.Loguro

"object" → SDK loaded successfully. Skip to “events not arriving” below.
"undefined" → SDK did not install. Continue below.

SDK did not install — checklist

data-api-key present and starts with brk_? If missing, the SDK logs a [loguro] No data-api-key provided. Snippet inactive. warning and exits. Open DevTools console to see it.
Script file actually loaded? Network tab → filter loguro.js. If 404 or blocked, check CSP (see below) and the src URL.
CSP blocking the script? Look for a console error like Refused to load the script ... because it violates the following Content Security Policy directive. Allowlist https://app.logu.ro in script-src.

Step 2: Events not arriving

You see window.Loguro but no events show up in the dashboard.

A. Check the Network tab

Filter on ingest.logu.ro (or your data-endpoint). You should see:

POST / for logs (one per call)
POST /batch for analytics (one per batch)

If you see none, the SDK is not firing — check data-analytics is set (or data-intercept/data-capture for logs).

If you see them but they’re red (failed), keep reading.

B. `net::ERR_BLOCKED_BY_ORB` or `ERR_BLOCKED_BY_CORB`

Chrome’s Opaque Response Blocking. Almost always a server-side CORS issue, not the SDK.

What’s happening:

The SDK sends POST with Authorization: Bearer ... and X-Request-Id custom headers. The browser sends a OPTIONS preflight first. If the server doesn’t respond with the right CORS headers, the browser blocks the body of the actual POST that follows.

What to check (using DevTools → Network → click the failing request → Headers tab):

1. The OPTIONS preflight response must include:

Access-Control-Allow-Origin: https://your-site.com   (or *)
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, X-Request-Id
Access-Control-Max-Age: 86400

2. The POST response must include:

Access-Control-Allow-Origin: https://your-site.com
Content-Type: application/json
X-Content-Type-Options: nosniff

Repro from a terminal:

curl -i -X OPTIONS https://ingest.logu.ro/ \
  -H "Origin: https://your-site.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: authorization, content-type, x-request-id"

If the response is missing any of the headers above, contact support — the fix is on the ingest server, not your side.

C. `429 Too Many Requests`

You’ve hit the project’s quota for the current period. Response body:

{
  "error": "Quota exceeded",
  "message": "Quota exceeded: 100001 would exceed limit of 100000",
  "quota": { "current": 100000, "limit": 100000, "remaining": 0 }
}

Action: upgrade your plan or wait for the next billing cycle.

D. `401 Unauthorized`

Your data-api-key is invalid or revoked. Generate a new one from project settings.

E. Events visible in Network as 202, but not in dashboard

Events arrive on the server (202 Accepted) but are then processed asynchronously. Typical lag is 30-90 seconds. If you still don’t see them after 5 minutes:

Check the project name / key in the Authorization header matches the project you’re looking at in the dashboard.
Check the dashboard’s date range filter — events with future timestamps (system clock skew) can be off-screen.

Step 3: Rate limit / circuit breaker

If you’re firing lots of events and some disappear silently:

Per-minute rate limit (default 1000). Excess events are dropped without warning.
Circuit breaker: after 5 consecutive transport failures (timeout, network down), the SDK pauses outbound for 60 seconds, then retries.

To diagnose:

// Verbose debug mode (not built into SDK, do it manually):
const orig = window.fetch;
window.fetch = function (input, init) {
  if (String(input).includes('ingest.logu.ro')) {
    console.log('[loguro debug]', input, init?.body);
  }
  return orig.apply(this, arguments);
};

This logs every outbound request to the console. Disable in production.

Step 4: SPA pageviews not firing

You navigate client-side, but no new pageview event appears.

Check:

data-analytics includes spa (or all). Just pageviews only fires the initial load.
Your router uses history.pushState under the hood. If it uses window.location.assign (full page reload), each route counts as a fresh page load — that’s a regular initial pageview, not SPA.
Some routers debounce/skip identical URLs. The SDK has a 50ms debounce on history changes — if your router fires pushState then immediately replaceState, that’s one pageview, not two. Intentional.

Verify manually:

history.pushState({}, '', '/test-route');
// Should see a new pageview in Network tab within ~50ms

Step 5: `sendBeacon` failures on `pagehide`

Some browsers (Safari, locked-down enterprise environments) silently fail sendBeacon. The SDK falls back to fetch with keepalive: true, which has the same behavior but explicit error reporting.

If you suspect this is happening:

Test in Safari with DevTools open
Look for beforeunload events firing without a corresponding network request
The fallback fetch will show up in Network as a normal request (might be cancelled on actual page unload, but the server still gets it)

Step 6: TypeScript build errors

If you see Property 'Loguro' does not exist on type 'Window', add the declaration from the API reference at the bottom of that page.

Step 7: Auto-events not capturing

You marked an element [data-loguro-event="..."] but clicks don’t fire events.

Check:

data-analytics includes auto-events (or all).
The attribute is exactly data-loguro-event, not data-loguroevent or data-loguro_event.
The click isn’t being stopped by another handler with e.stopPropagation() before the SDK’s capture-phase listener runs. The SDK listens at the capture phase, so most propagation-stopping handlers won’t block it — but custom phase shenanigans can.
The element is inside a shadow DOM. The SDK doesn’t traverse shadow boundaries. Move the attribute to the shadow host instead.

Still stuck?

Open a support ticket with:

Your project ID
A screenshot of DevTools → Network → the failing request → Headers tab (both request + response)
The <script> tag you have on your site (redact the API key)
Browser + version

We can usually narrow it down within an hour.