Skip to main content
Every RUM SDK sends the same JSON events to one endpoint. A client without an SDK, such as a native app that has no SDK yet, sends the same events with an HTTP request. An event has a type, a date, the session and the view it belongs to, and an object named after its type that carries the details. The JSON Schema of an event ships with the source as contracts/rum/events/v1.schema.json, together with valid and invalid example events.

Send events

The answer

The answer reports every event on its own, so one bad event does not discard the rest of the request. A request whose events are all bad still answers 200, with accepted set to 0. A request that cannot be read at all fails as a whole: 400 for a body that is not JSON, an unsupported Content-Encoding, or a gzip stream that cannot be decoded; 401 or 403 for a token that is missing, revoked, or without rum.write; 413 for a request over the limits above. An event is rejected for one of these reasons: An SDK reports rejected events through its error callback and does not send them again.

Rules

  • date is the time the event began, in epoch milliseconds. The date of a view is the start of the view and never changes between its revisions.
  • Every duration, and every time relative to the start of a view, such as performance.lcp.timestamp or resource.dns.start, is an integer number of nanoseconds. Round before sending.
  • A view is sent again with a higher view.revision and its counts so far, whenever something in it changes. MoleSignal keeps the highest revision. Counts are cumulative, never deltas.
  • A client sends no session event. MoleSignal derives the session from its views: its start and end, duration, counts, landing and exit page, and whether a replay was recorded.
  • session.start, in epoch milliseconds, is optional and expected. A node that does not know a session yet uses it to tell a session that began moments ago from one it lost track of.
  • application.id is optional. The application is the one the client token is bound to, and a different value is rejected.
  • geo and network are written by MoleSignal and ignored when sent. So is retention: retention.rate is the share of such rows that was kept, in percent, and retention.filter is what kept the row (the id of a filter, default, or errors for an error of a session that was not kept). Totals are worked out with them.
  • A field the schema does not know is accepted and kept. A field the schema knows with the wrong type or value rejects the event.
  • error.frames carries the structured stack that source maps, mapping files, and native symbol files are applied to. error.stack is the same stack as text for display and search.

Attributes of every event

Identifiers match A-Z, a-z, 0-9, ., _, :, and -, up to 128 characters. Text attributes of usr, account, and the device are limited to 256 characters.

View

A view event carries a view object with these fields next to the url, name, and id above.

Action

Error

Resource

Long task

Vital

What MoleSignal adds

  • Place: the country, subdivision, city, continent, and coordinates of the client IP address, looked up in the DB-IP City Lite database. The address itself is kept only when the application keeps it.
  • Browser, system, and device: for browser events that carry none, parsed from the User-Agent header. A crawler becomes device.type: bot. Values an SDK sends win.
  • URL parts: view.url_host, view.url_path, and view.url_path_group, and the same for resource.url.
  • Long task scripts: long_task.top_script.source_url, long_task.top_script.function, and long_task.top_script.invoker_type, from the entry of long_task.scripts that ran the longest. A browser that reports no scripts leaves them empty, and what a client sends in these columns is dropped.
  • Sessions: the rum_sessions row of each session, derived from its views.
Before an event is stored, the application’s choices are applied: the sessions it does not keep are left out, and the sensitive text it chose to take out is replaced. The IP address and the place follow the settings of the application.

Where the events are stored

Each type has its own ordinary Logs stream, created with the first application. The streams have a fixed schema, so a value of the wrong type never changes a column. Columns are the flattened names of the event, such as view.performance.lcp.timestamp and resource.status_code. Browse them in the RUM explorer, or query the streams with SQL on Logs.

Example

A request with a view that is sent again, a failed request, and the error it caused:

RUM applications

Create the application a client token is bound to.

RUM explorer

Search the events by type and field.
Last modified on October 26, 2026