← All posts

Windows on the frontend

console.error is not everything — Output Console catches the errors you do not see

15 May 2026 · by JustZix Team

The Output Console in JustZix shows what a page writes to the console — without opening DevTools. But for a long time it only showed what the code explicitly called via console.log. And half of what you see in DevTools does not come from console.log at all. As of version 2.13.86 that changed.

console.error is not the same as an error

It is easy to conflate two things:

• console.error('something') — the code deliberately logs something at the error level.
• throw new Error('something') — the code crashed. Nobody called console.error. And yet DevTools shows a red entry with a stack trace.

Chrome catches crashes itself and shows them in the console. If the Output Console only wraps console.*, those crashes slip past it — and they are often the most important things, because they are what breaks the page.

What is captured now

1. Uncaught exceptions

An uncaught throw, a syntax error, a runtime error — Chrome then dispatches an error event on the window object. The Output Console listens for that event and records the message together with the stack trace and a file:line:column location.

2. Unhandled promise rejections

A someAsync().then(...) with no .catch, or an await that threw and nobody caught it — Chrome dispatches an unhandledrejection event. The Output Console listens for it and shows the rejection reason as an error entry prefixed with "Unhandled promise rejection".

Why the capture phase

Both listeners are attached in the capture phase. The reason: the page may also have its own error or unhandledrejection handler that calls preventDefault() or stopPropagation(). The capture phase runs before the bubbling phase, so the Output Console sees the event before the page code can silence it.

A 30-second test

Open a JS Console (or a TEMP JS Console via Ctrl+Alt+J) and type:

throw new Error('test boom')

A red entry with a stack trace should appear in the Output Console. Now:

Promise.reject('async boom')

"Unhandled promise rejection: async boom" should appear. If you see both — error capture works.

What we still do NOT catch — and why

• CSP violations. They have a separate securitypolicyviolation event — possible to add later, out of scope for now.
• Network 4xx/5xx errors. A failed fetch with a 404 or 500 is a successfully completed response — Chrome shows it in the Network tab, not the console. We only catch it if your code itself throws after checking response.ok.
• Internal Chrome warnings. Messages like "Autofocus processing was blocked" are generated by the browser itself — they cannot be intercepted from page level.
• Resource load failures. A failed <img> or <script> is sometimes caught by the capture-phase error listener, but not always — it depends on the resource type.

These are deliberate boundaries, not gaps. The Output Console shows the page's JavaScript errors — what you usually want to see — not the browser's entire diagnostic noise.

Use case — production monitoring without DevTools

Snap an Output Console to the edge of the tab and leave it. You open your own site after a deploy — if something crashes, you see it immediately, even if the error does not come from your console.error. For a QA tester that is the difference between "the page looks OK" and "the page looks OK, but an uncaught TypeError is firing in the background".

See also

• Output Console — the full window write-up
• TEMP panes — Output Console under the Ctrl+Alt+K shortcut
• Injecting on CSP-strict pages — how the console hook works

Install JustZix — and see the page's errors before your users do.