Browser Console Messages

Developers watch the browser console while they build a page, but nobody looks at it in production. Errors logged there are the first sign that a script failed, a resource did not load or an API is deprecated, and they only show up in a real browser running the page’s JavaScript. This auditor loads the page in a headless Chromium as 37AuditsBot, waits for it to load and settle, and reports every console message by its level: errors fail, warnings warn, and the remaining log, info and debug messages are listed on the success check without changing the verdict.

​

How it works

1. Load — launches a headless Chromium, opens the audited URL as 37AuditsBot and waits up to 60 s for the page’s load event. The navigation that returns HTTP 403, HTTP 429 or a Cloudflare challenge ends the audit with 590; a navigation with no response or any other HTTP 4xx/5xx answer ends it with 500; a browser failure, after one relaunch on a crash, ends it with 501.
2. Settle — waits up to 15 s more for the network to go idle, then 1.5 s for late assets. A page that keeps the network busy (polling, beacons, long-lived connections) is audited with what it logged by then and warns (301).
3. Collect — every console message the page wrote while loading is recorded with its type, text and the script location the browser reports.
4. Rules — each error message fails (400, one check per message) and each warn/warning message warns (300, one check per message). The check’s resource is the script location when the browser reports one, otherwise the audited URL.
5. Aggregate — FAIL wins over WARNING; when the page logged no error and no warning and went network-idle, the audit is SUCCESS (200) and the check data lists the info/debug messages it did log.

​

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

Why console errors matter

• A console error is usually an uncaught exception: the script that was running stopped, so whatever it was doing (a form validation, a menu, a checkout step, a tracking call) silently did not happen for that visitor.
• Nobody watches the console in production, so these failures surface as lost leads or support tickets rather than as bug reports.
• Search engines render JavaScript; a page whose scripts fail may be indexed without the content they were meant to render.

​

Warnings and the network-idle wait

• Warnings are usually deprecation notices, failed optional resources or insecure practices. They cost nothing today but turn into errors when the browser removes the deprecated API.
• The auditor waits 60 s for the load event and 15 s more for the network to go idle. A page that keeps polling, sending analytics beacons or holding long-lived connections never goes idle; the audit then reports what the page logged up to that point and warns with 301, because messages logged later are not captured.

​

Changes from the previous version

• log, info and debug messages no longer produce one SUCCESS check each; they are listed in the data of the single 200 check.
• A page that never goes network-idle is now a WARNING (301) instead of a note appended to the message, so a page that logs nothing but never settles is WARNING where it used to be SUCCESS.
• A page that answers HTTP 4xx/5xx is now an ERROR (500) instead of being audited as if it had loaded.
• A browser failure that survives the relaunch is now ERROR with code 501 instead of an uncoded check.

​

What this auditor does not check

• Only the messages logged while the audited URL loads are read; messages logged after a click, a scroll or a later interaction are not.
• The console is read through a headless Chromium on Linux; a message specific to another browser or to a mobile device is not seen.
• The page is loaded once; a message that only appears intermittently (a flaky third-party script, an ad) may be missed or reported on one run and not the next.
• The auditor does not judge whether a message comes from your own code or from a third-party script; both are reported with the location the browser gives.