The browser SDK writes logs with the session and the view they happen in, so a log leads to its replay and a session shows what the page wrote. Nothing is sent until a log is written or the console is asked for.
A logger leaves out what is below its level, and takes debug, info, warn, and error. With an error as its third argument, a log keeps its type and stack.
To also forward what the page writes to the console:
What the console prints stays as it is. Keep this off where the console may hold personal data, or look at what the application takes out at intake, which covers the text and stack of a log too.
Where they are
- On the session page, the Logs tab under the replay lists them in order, lights the one the replay has reached, and moves the replay to the moment of a row.
- In the explorer, Logs is a type of row.
- In Logs, the stream
rum_logs is an ordinary log stream, with level and message, so the level histogram and the rest work as for any log.
A session the application does not keep leaves no logs behind. Logs are not counted on the view.
What goes wrong in the SDK
When something goes wrong in the SDK itself (an event the server refuses, a beforeSend that throws), it says so as a log with the logger molesignal-rum and the origin sdk, each thing once and a few per page load. What goes wrong on the way to the server is not among them, since a log would not arrive either. Turn this off with trackSdkErrors: false. onError is called either way.
Fields
Last modified on October 31, 2026
