Troubleshooting

You pasted the snippet, reloaded your site, and the onboarding screen still says it’s waiting for your first event. Every cause below leaves that screen in the same waiting state — but most of them do leave a signal in the browser’s DevTools. Work down the list in order and check each one.

1. The write key doesn’t match the project

Each project has its own wk_ write key. Compare the key your page passes to kilden.init against the one shown on the project’s onboarding or settings screen, character by character.

This one is nasty because a wrong-but-valid key doesn’t fail: the request returns 200 and your events land in whichever project that key belongs to (a teammate’s, a staging project) — they exist, just not where you’re looking. An invalid or revoked key is different: it’s rejected with 401 (step 5).

2. No request leaves the browser

Open DevTools → Network, reload the page, and filter by the capture host (ingest.kilden.io). You should see a POST within a few seconds — loading the page emits a $pageview automatically.

If no request appears:

• The snippet isn’t on the page. Check the served HTML — right-click → View page source — not your framework template. Layouts, template inheritance, CDN caches and build pipelines routinely serve a page without the change you just made.
• Something blocks it before sending — the next two sections.

3. Ad blockers and privacy modes

uBlock Origin, Brave Shields, Safari and Firefox strict tracking prevention, and corporate DNS filters block requests to analytics-shaped hosts. The POST shows as blocked or failed in DevTools, or never appears at all.

Test in a clean browser profile, or an incognito/private window with extensions disabled. If events arrive there, your snippet is fine.

Note this isn’t only a debugging artifact: some fraction of your real visitors block the same requests, so browser numbers always read slightly below server truth. That’s inherent to client-side analytics, not a misconfiguration.

4. Content-Security-Policy

If your site sets a Content-Security-Policy header, it must allow both Kilden hosts: script-src for the CDN that serves the SDK, connect-src for the capture endpoint:

Content-Security-Policy: script-src 'self' https://cdn.kilden.io; connect-src 'self' https://ingest.kilden.io

(Self-hosted instances use their own hosts — adjust accordingly.) CSP violations do show up as explicit errors in the DevTools Console; this is the one failure mode that isn’t silent, if you look there.

5. The request fires but returns an error

Click the request in the Network tab and read the status:

• 401 — the write key is wrong or was revoked (unknown write_key). Back to step 1.
• Other 4xx — the plain-text response body says exactly what’s malformed. See the Capture API error table.
• 5xx or a network failure — the SDK retries transient errors silently; a brief blip loses nothing.

6. Send a test event without touching your site

The onboarding screen has a Send a test event button: it pushes an event through your project’s real pipeline server-side, so it proves ingestion end-to-end for the project you’re looking at — even before your snippet works. If the test event arrives but your pageviews don’t, the pipeline is fine; it doesn’t rule out a key mismatch, though, so recheck step 1 first (your page could carry another project’s valid key), then steps 2–4.

The equivalent from a terminal — the payload shape is documented in the Capture API:

curl -X POST https://ingest.kilden.io/capture \
  -H 'Content-Type: application/json' \
  -d '{
    "write_key": "wk_YOUR_KEY",
    "sent_at": "2026-01-01T00:00:00Z",
    "batch": [{
      "uuid": "'"$(uuidgen)"'",
      "event": "test_event",
      "distinct_id": "curl-test",
      "properties": {},
      "timestamp": "2026-01-01T00:00:00Z"
    }]
  }'

The $(uuidgen) generates a fresh uuid on every run — it’s the idempotency key, and a repeated uuid deduplicates into a single event, which looks exactly like the problem you’re debugging.

Still stuck?

Keep the live tail open next to DevTools — events appear there within a couple of seconds of arriving, so you get instant confirmation the moment any step above starts working (the quickstart shows where to find it). If none of them does, ask us on GitHub and include the request status and response body from the Network tab.