Why console.log Isn't Enough: Capturing the Full Console in Bug Reports

Most bug reporting tools only capture console.error. But the warning that fires two seconds before the error — or the debug log that shows exactly what data was loaded — lives in the other four levels.

The five console levels

The browser console has five output methods, each with a different severity and default visibility:

console.error('Payment failed: invalid_amount')   // always visible, red
console.warn('Stripe not loaded yet')            // visible, yellow
console.info('Cart initialized: 3 items')        // visible, blue
console.log('formatAmount called with: NaN')     // visible, default
console.debug('checkout.js:142 event fired')    // hidden by default

When a bug reporting tool says "console errors captured," it typically means only console.error. The other four levels — which often tell the story of how the system reached the error state — are discarded.

The warning that predicts the error

Imagine a payment form that crashes. The console.error says:

TypeError: Cannot read properties of undefined (reading 'toFixed')

That tells you where it crashed. But the console.warn from 800ms earlier tells you why:

Warning: formatAmount received NaN — expected number. Check cart.js line 89.

If your bug report only captures errors, the developer sees the crash but not the warning that caused it. That warning is the actual bug — the crash is just the consequence.

The log that shows what data was loaded

Many bugs are data shape issues: the API returned an unexpected structure, a field was missing, or a value was the wrong type. Developers instrument their code with console.log statements specifically to make these visible:

          // In cart.js

          console.log('Cart data received:', cart);

          // Output: Cart data received: { items: [], total: undefined }

If the bug reporting tool only captures errors, this log disappears. The developer has to reproduce the issue locally and add their own logging to see what data was loaded — if they can reproduce it at all.

When debug logs are the only clue

Some bugs only occur in production, on specific devices, or with specific authentication states. A developer can't reproduce them locally. The only window into what happened is the captured console — and if debug-level logging is excluded, that window closes.

console.debug is designed for exactly this: verbose output that's filtered by default in the browser console but can be turned on. Many well-instrumented applications log detailed state transitions, API responses, and calculated values at the debug level specifically so that production bugs have a trail.

What "captures from page load" actually means

There's another dimension beyond which levels are captured: when capture begins.

If a bug reporter installs its console hook after the page loads, it misses everything that happened during initialization — which is often where the most important errors occur. A Stripe element that failed to load. A session token that wasn't set. A feature flag that evaluated to the wrong value.

Site Reviewer patches all five console methods at document_start — the earliest possible injection point, before any user JavaScript runs. Every console output from the very first script execution is captured.

The 200-entry circular buffer

Console logs can be voluminous. If a page logs 2,000 entries before a user clicks "Report," the most recent entries — the ones that happened right before the bug — are the most relevant.

Site Reviewer keeps a circular buffer of the last 200 console entries. When a report is submitted, the most recent 200 are included. Old entries are dropped as new ones come in, so memory usage stays bounded and the report always contains what's most relevant.

Configuring what's captured

Not every team wants all five levels in every report. Verbose console.log and console.debug output from analytics and third-party scripts can add noise. Site Reviewer provides a captureAllConsole setting: when off, only errors and warnings are captured; when on, all five levels are included.

The default is to capture all levels — because you can always filter noise out of a report, but you can't add information that wasn't captured.

Why `console.log` Isn't Enough: Capturing the Full Console in Bug Reports