On this page
Debug logging
Last updated
Configurable console log levels prefixed with [vTilt] for filtering. The default is warn — errors and warnings always reach you. Two ways to set the level.
When troubleshooting initialisation, identity, or event delivery, the browser SDK emits level-gated messages prefixed with [vTilt] so you can filter them in the browser DevTools console.
The default level is warn — the SDK will surface errors and warnings out of the box, with no opt-in required. Production consoles stay quiet because the level taxonomy reserves info and debug for things you only want while wiring up or live-debugging.
#Two ways to set the level
You can control the SDK's console verbosity from two independent places. Init-time configuration always wins when both are set.
#1. In the snippet (build-time)
Pass log_level (or debug: true) to vt.init(). This locks the level for that page load and ignores the dashboard setting.
vt.init('YOUR_PROJECT_TOKEN', {
api_host: 'https://www.vtilt.com',
log_level: 'debug', // or `debug: true` for the same effect
})You can also generate a snippet with the level baked in from Project Settings → Integration Script in the dashboard — pick a level in the Console log level dropdown and copy the generated snippet.
#2. In the dashboard (runtime, all visitors)
Open Project Settings → Default Configuration → Diagnostics and pick a level. The SDK fetches this on boot via /api/decide (cached for 60 seconds) and applies it to every visitor whose snippet did not hard-code log_level / debug.
Typical use case: support is helping a customer reproduce a bug. Flip Diagnostics to debug for a few minutes, ask the customer to reload the page, then revert it.
#Log levels
Each level includes the levels above it (e.g. info shows info, warn, and error). Scopes after the colon (e.g. :autocapture) name the SDK module that emitted the message — useful for filtering in DevTools.
| Level | What it surfaces | Example output |
|---|---|---|
none | Nothing. Hard mute for shared kiosk consoles or when third-party tooling is noisy already. | (no output) |
error | The SDK or your input is broken in a way that prevents work. | [vTilt]:request transport unavailable<br />[vTilt]:identify invalid input |
warn | Degraded but recovering — fallback paths, retries, deprecated APIs, missing browser features. | [vTilt]:storage localStorage disabled, falling back to memory |
info | One-time lifecycle events you want while wiring the SDK up. | [vTilt]:autocapture started<br />[vTilt]:replay session started |
debug | Per-event trace useful when filing a bug — every captured event, every autocapture skip, queue flushes, request URLs. | [vTilt]:capture $autocapture { distinct_id, $current_url, ... }<br />[vTilt]:autocapture skip class_blocked |
#Filtering in DevTools
All output starts with [vTilt], so you can filter to just the SDK:
[vTilt]Or narrow to a single module by including the scope:
[vTilt]:autocapture#Going completely silent
For environments where any console output is unacceptable (shared kiosk consoles, embedded webviews you don't own), set:
vt.init('YOUR_PROJECT_TOKEN', {
api_host: 'https://www.vtilt.com',
log_level: 'none',
})This is the only way to suppress errors as well — the default warn floor will still let error and warn through.