> ## Documentation Index
> Fetch the complete documentation index at: https://docs.37audits.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Browser Console Messages
> Loads the page in a real browser and reports the errors and warnings its scripts write to the console.
**Performance Auditor** — opens the audited page in a headless Chromium, collects everything its scripts write to the browser console while it loads, and reports every `error` as a failure and every `warning` as a warning.
A console error is usually a script that failed, so a form, a menu or a widget may be broken for visitors without anyone noticing.
The page runs in Chromium with its JavaScript, so the audit sees what visitors' browsers see, not just the HTML.
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.
| CheckCode | Status | When it fires | Recommendation | Why it matters |
| - | - | - | - | - |
| `37A-BrowserConsoleMessagesAuditor-400` | `FAIL` | The page logged an `error` message to the browser console. One check per message. | Fix the script at `{location}` so it stops logging the error "`{text}`" while loading `{url}`. | A console error usually means a script failed, so a feature of the page may be broken for visitors without anyone noticing, and search engines that render JavaScript may index an incomplete page. |
| `37A-BrowserConsoleMessagesAuditor-300` | `WARNING` | The page logged a `warn`/`warning` message to the browser console. One check per message. | Review the script at `{location}` and resolve the warning "`{text}`" while loading `{url}`. | Console warnings flag deprecated APIs, failed resources and insecure practices that browsers will soon stop tolerating, so what is only a warning today turns into a broken feature after the next browser update. |
| `37A-BrowserConsoleMessagesAuditor-301` | `WARNING` | The page did not go network-idle within 15 s after its `load` event, so the console was read before the page settled. | Reduce the polling, beacons or long-lived requests that keep `{url}` busy after it loads, so the page goes network-idle within 15 s and every console message is captured. | A page that keeps the network busy after it loads drains visitors' battery and data, and the audit has to read the console before the page settles, so errors that appear later go unreported. |
| `37A-BrowserConsoleMessagesAuditor-200` | `SUCCESS` | All rules passed: the page logged no error and no warning. Message says `No console messages were logged while loading {url}.` or `Only {n} info/debug console messages were logged while loading {url}; no errors or warnings.`; the check data lists those messages. | — | — |
| `37A-BrowserConsoleMessagesAuditor-500` | `ERROR` | The browser got no response for the audited page, or an HTTP 4xx/5xx answer other than a block. | Make sure `{url}` answers with HTTP 2xx, then run the audit again. Last error: `{error}`. | — |
| `37A-BrowserConsoleMessagesAuditor-501` | `ERROR` | The headless browser failed to load the page (after one relaunch when it crashed). | Make sure `{url}` loads in a headless Chromium browser, then run the audit again. Last error: `{error}`. | — |
| `37A-BrowserConsoleMessagesAuditor-590` | `ERROR` | The audited page answered HTTP 403, HTTP 429 or a Cloudflare challenge, so 37AuditsBot was blocked before it could read the page. | Allow 37AuditsBot in your firewall or bot protection: allowlist its user agent, or verify its Web Bot Auth signature. See [https://www.37audits.com/bot](https://www.37audits.com/bot). | While 37AuditsBot is blocked this audit cannot look at the site, so problems on it go unreported. |
## Output documentation
| Status | Description | Test logic |
| - | - | - |
| **SUCCESS** | The page logged no console error or warning | No `error` and no `warn`/`warning` message, and the page went network-idle within 15 s (`200`); info/debug messages are listed in the check data. |
| **WARNING** | Something to review in the console, or the page never settled | At least one `warn`/`warning` message (`300`, one check each), or the page did not go network-idle within 15 s (`301`). |
| **FAIL** | A script logged an error | At least one `error` message (`400`, one check each). |
| **ERROR** | The auditor could not load the page | No response or HTTP 4xx/5xx (`500`); browser failure after the relaunch (`501`); site blocked 37AuditsBot (`590`). |
## 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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.