An injection can load perfectly and still go wrong once it runs. A script references something that is not there, a promise rejects and nothing catches it, a typo throws on the third click. None of this shows up in the admin. The browser raises it on the visitor’s screen and moves on. The Errors screen catches those and brings them back where you can see them.
What it records
A small script on the front end listens for JavaScript runtime errors and unhandled promise rejections coming from your injections. Each one is recorded with its message, where it happened, and the page it fired on. The screen lists them as cards, newest first, in the same style as the Conflicts screen.
It names the injection
This is the part that saves time. Every JavaScript injection carries a marker that ties an error back to it, so an error names the exact injection it came from rather than reading as source unknown. That holds even when the error fires later, from a timer, an event handler, or a promise, long after the script first ran. An inline script inside a head or body HTML injection, a self-contained toy for example, is tagged the same way.
HTML and CSS are not here
The log lists runtime JavaScript only, because that is what the browser actually raises. HTML and CSS mistakes are not runtime errors: the browser parses HTML leniently and skips a bad CSS rule without complaint. Those are covered in other ways, by the injection preview where you see the rendered result, and by Conflict detection where overlapping code shows up.
Clearing and exporting
The log holds the most recent errors and rolls older ones off. Export downloads the full log as a file in the same format as the conflicts report. Clear log wipes it, which is the natural thing to do after you have fixed something and want to confirm it stays quiet. The injection these errors come from is the one you write on the Injections screen.
Number Nine is running a light roast this morning. Della has opinions about it.
