Documentation

Ship Failior browser monitoring without guesswork.

These docs are written for engineers who want the actual runtime behavior, not vague setup copy. Start with the RUM install guide, enable shared API failure incidents only when you want them, and use the local harness to verify every metric and incident flow before shipping.

Guide 1

RUM overview

Failior RUM is a browser collector for page-speed signals, page views, and optional shared API failure incidents. It is designed to stay small, use one script tag by default, and keep the backend in charge of sanitization, geo inference, browser parsing, and incident grouping.

One script tag Server-side sanitization SPA route tracking Opt-in incident logging Speed signals and segments

What it captures

Page views, LCP, INP, CLS, FCP, TTFB, browser family, device type, coarse country, and optional shared request failure samples when incident logging is enabled.

What it does not capture

Query strings, request bodies, response bodies, auth headers, page content, or unrestricted custom data. Paths and request signatures are normalized before storage.

Guide 2

Install and configure

The cleanest install path is: create a RUM site in the product, set allowed hosts, optionally enable shared API failure incidents, then paste the generated script tag into the page head.

Default recommendation

Leave incident logging off unless you explicitly want shared API failure grouping. Page-speed telemetry works without it.

Generated script tag

<script
  async
  src="https://rum.failior.com/rum/v1/rum.js"
  data-site-token="rum_pub_xxxxx"
  data-endpoint="https://api.failior.com/api/rum/ingest"
  data-environment="production"
  data-capture-api-errors="true"
></script>

ESM package install

import { bootFailiorRUM } from "@failior/rum-browser";

bootFailiorRUM({
  siteToken: "rum_pub_xxxxx",
  endpoint: "https://api.failior.com/api/rum/ingest",
  environment: "production",
  captureApiErrors: true
});
  1. Create a site in the RUM tab, add the exact hosts you want to allow, and copy the generated script tag.
  2. Paste the tag into the page head of the site you want to monitor.
  3. If you want shared request-failure incidents, enable the checkbox during site setup so the tag includes data-capture-api-errors="true".

Configuration fields

Field Purpose
data-site-token Public site identifier used by ingest.
data-endpoint Where telemetry is posted.
data-environment Optional environment tag such as production or staging.
data-release Optional deployment label if your team wants it. Not required for incidents.
data-capture-api-errors Opt-in shared request failure sampling for the incidents tab.
Guide 3

Speed signals

The dashboard groups page-speed data under speed signals. The exact labels can switch between developer acronyms and simpler wording in preferences, but the underlying measurements stay the same.

LCP / Main contentWhen the main visible content finishes rendering. Best for judging load experience.
INP / Input delayHow quickly the page responds after someone clicks, taps, or types.
CLS / Layout shiftHow much visible content jumps around while the page settles.
FCP / First paintWhen the first visible content appears, before the main content is necessarily complete.
TTFB / Server responseHow quickly the server begins responding to the initial document request.
Page views and sessionsTraffic context for the signals, so low-volume noise does not look like a trend.

What to expect in the dashboard

  • Overview focuses on page traffic plus one selected speed signal at a time.
  • Segments breaks the same data down by host, browser, device, and country.
  • Incidents appears when the site has incident logging enabled and shared failure patterns exist.
Guide 4

Incident logging

Shared API failure incidents are deliberately opt-in. When enabled, the browser collector samples failing request patterns and the backend promotes only shared, repeated failures into incidents.

Noise filtering is intentional

One browser failing one request once is treated as noise. Incidents are created only when multiple sessions share the same normalized request pattern and failure type.

What is grouped

  • Request host
  • Normalized request path
  • HTTP method
  • Failure kind such as http_5xx or network
  • Session spread and failure rate

What is ignored

  • Repeated identical failures from the same session within a short window
  • The RUM ingest request itself
  • The localhost simulator control request
  • Single-session noise that never spreads

Auto-resolution behavior

Incidents resolve only after the backend sees convincing healthy traffic after the last failure. They are not marked resolved just because traffic went quiet.

Guide 5

CSP requirements

If your site uses a strict Content Security Policy, you need to allow the Failior browser script to load and the ingest endpoint to receive telemetry. The generated script tag already contains the right public URLs, but your CSP still needs to permit them.

Minimum CSP additions

script-src 'self' https://rum.failior.com;
connect-src 'self' https://api.failior.com;

When they matter

  • script-src must allow the RUM script origin.
  • connect-src must allow the ingest endpoint.
  • If your CSP is report-only, use it to confirm the integration before enforcing.

Example policy fragment

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://rum.failior.com;
  connect-src 'self' https://api.failior.com;

Keep using the generated script tag from the product UI. If your organization uses different Failior subdomains, mirror those exact script and ingest origins in CSP instead of hard-coding the example hosts above.

Guide 6

Graph SDK

The graph SDK is for backend or workflow instrumentation. It lets your application send graph packets to Failior so teams can see which node failed and what path was affected.

How graph ingest works

  • Create a stable graph id for the workflow you want to trace.
  • Emit node ids in the order the workflow executes.
  • Send one packet when the workflow ends so Failior can map the path and any failure.

Minimal shape

{
  "graph_id": "checkout-flow",
  "node_id_list": ["api", "db", "queue"],
  "did_error": false,
  "timestamp": "2026-03-30T12:00:00Z"
}

Download SDKs

Go SDK JavaScript SDK Python SDK C# SDK C++ SDK

These downloads are the public source files for the current SDK examples. Use them as a starting point, then set your graph id and Failior ingress base URL in application code.

Go example

t := failiorsdk.Track(
  ctx,
  "<graph id>",
  failiorsdk.WithBaseURL("https://api.failior.com"),
)
defer t.End(&err)

t.Node("<node id 1>")
t.Node("<node id 2>")

JavaScript example

const failior = require("/sdk/javascript-download.js");

const t = failior.track("<graph id>", {
  baseURL: "https://api.failior.com",
});

t.node("<node id 1>");
t.node("<node id 2>");
await t.end(err);