Made by Rune Andersen @ Copenhagen, Denmark
Amplitude Analytics logo

Debug Amplitude in Chrome DevTools

To debug Amplitude Analytics in Chrome DevTools, install the free Event Watcher extension and open its panel: every Amplitude Analytics request is captured the moment it fires, decoded by a dedicated parser into named events, readable parameters, and consent signals, and cross-referenced against the visitor's consent state. Event Watcher has listed Amplitude Analytics under Analytics since v1.0.0, and flags any Amplitude Analytics event that fires without analytics consent.

Product analytics for tracking user behavior, retention, and feature adoption. Part of the Amplitude product family; Session Replay, Experiment, and Guides and Surveys are detected as separate tools.

Last updated:

Category
Analytics
Detected via
Network requests: Event Watcher matches the request URLs this platform sends
Consent category
Analytics / statistics consent: Event Watcher flags Amplitude Analytics activity that fires without it
Dedicated parser
Yes: requests are decoded into named events, parameters, and consent signals, not just raw URLs
Supported since
Event Watcher v1.0.0 (2026-02-20)
Show the URL patterns Event Watcher matches
  • api.amplitude.com
  • api2.amplitude.com
  • api.eu.amplitude.com
  • amplitude.com/2/httpapi
  • amplitude.com/batch
  • analytics.amplitude.com
  • regionconfig.amplitude.com
  • cdn.amplitude.com
  • cdn.eu.amplitude.com
  • regionconfig.eu.amplitude.com
  • analytics.eu.amplitude.com

What Amplitude traffic looks like

The Amplitude browser SDK batches aggressively: one request often carries several events queued since the last flush.

Endpoint pattern
api2.amplitude.com/2/httpapi (older SDKs: api.amplitude.com; EU-residency projects: api.eu.amplitude.com); amplitude.com/batch is a dedicated batching endpoint. Config requests to regionconfig.amplitude.com and SDK loads from cdn.amplitude.com (and their .eu variants) are part of the same footprint but carry no events
Transport
JSON POST body with two things at the top level: the project's api_key and an events array; older instrumentation sometimes sends URL-encoded form data with the events JSON in an e parameter instead
Key parameters
event_type event name (SDK-generated names are bracketed, like [Amplitude] Page Viewed) · user_id / device_id the identity pair · session_id millisecond timestamp marking session start · event_properties / user_properties the custom payload where tracking-plan drift shows up

A typical event batch, as Event Watcher captures it:

{
  "api_key": "a1b2c3d4…",
  "events": [
    {
      "event_type": "[Amplitude] Page Viewed",
      "user_id": "user@example.dk",
      "device_id": "3f6a91…",
      "session_id": 1754640000000,
      "event_properties": { "page_path": "/pricing" }
    }
  ]
}

One vendor, four tools in the panel

Since Event Watcher v1.5.0 the Amplitude product family is split into separate named tools, so a site running the full stack shows up to four Amplitude tools in the panel instead of one aggregate entry:

  • Amplitude Analytics: the event traffic described above.
  • Amplitude Session Replay (detected since v1.3.0): the recording add-on, matched on its own sr-client-cfg.amplitude.com config and api-sr.amplitude.com ingest hosts.
  • Amplitude Experiment: feature flags and A/B experiments, served from the separate lab.amplitude.com endpoint family (api.lab and flag.lab).
  • Amplitude Guides and Surveys: the in-product engagement widgets, on the gs.amplitude.com and engagement-static.amplitude.com hosts.

All four have EU-residency host variants and are matched in both regions. The split also separates consent expectations: Analytics and Session Replay are checked against analytics consent, while Experiment and Guides and Surveys count as functional.

Debugging Amplitude with Event Watcher

  • The Amplitude parser handles all the body formats: JSON body, form-encoded e/events parameters, and query-string variants.
  • Each batched request unpacks into individual events, showing the event name, user ID, device ID, session ID, and the full event and user property objects per event.
  • Verify a tracking plan against the wire: filter to Amplitude, trigger the interaction, and read the decoded event_properties instead of un-base64ing DevTools payloads by hand.
  • The api_key is surfaced too, which settles "which project is this actually sending to" in one glance.

Amplitude and consent

Analytics consent

The extension checks Amplitude against analytics consent. Amplitude has no consent-mode-style degraded ping: a request reaching /2/httpapi before the CMP grants analytics is a straightforward pre-consent fire, marked as such and counted in the violations tally.

The usual root cause: the SDK initializes on page load with a device ID cookie already set, while the consent gate only wraps the track() calls. Identity establishment then precedes consent even when events are held back.

Common debugging scenarios

  • Events show in the panel but not in Amplitude Charts. Check the decoded api_key against the intended project; staging keys in production are a classic.
  • Session counts look inflated. Compare session_id across consecutive events; a new value on every event means the SDK re-initializes per page instead of persisting.
  • Anonymous users never merge. Inspect user_id vs device_id on events before and after login to confirm the identify call actually landed on the wire.
  • A property is undefined in charts. Find the event in the stream and check event_properties as sent; the gap is usually upstream in the dataLayer, which push source attribution can pin to a script.
  • Events fire before the banner. The pre-consent badge plus the violations counter make the audit concrete instead of anecdotal.

See Amplitude traffic on your own site

Free, no account, runs entirely inside Chrome DevTools.

Add to ChromeFree on the Chrome Web Store

Related guides

More analytics platforms