Environments & releases

Separate your tiers so test traffic never pollutes production numbers, and tag each deploy so you can pin a regression to the build that introduced it.

The four environments #

An app has four environments. Use them to keep clean tiers apart:

production: real users. The numbers you report on.
staging: pre-release verification against production-like data.
development: local and integration work.
preview: ephemeral per-branch or per-PR deploys.

Keeping them separate matters because each environment selects its own ingest policy, so you can sample heavily and cap tightly in development while collecting everything in production, and because mixing test sessions into production skews your vitals, error rates, and conversion counts.

Set the environment #

Set environment in your init call to match the deploy. The console pre-fills it based on the environment you picked on the Install tab; drive it from your own build configuration so each deploy reports under the right tier.

init with environment js

amb('init', {
  appId: 'storefront',
  environment: 'staging',     // production | staging | development | preview
  endpoint: 'https://rum-ingest.example.com/v1/events',
  defaultConsent: 'granted'
});

Tag releases #

The optional release field carries a build, commit, or version tag. It is stored on rum.events.release, so every event knows which deploy produced it. Set it from your CI to a value that maps back to a specific build.

init with release js

amb('init', {
  appId: 'storefront',
  environment: 'production',
  endpoint: 'https://rum-ingest.example.com/v1/events',
  release: '2026.05.0+a1b2c3d',   // -> rum.events.release
  defaultConsent: 'granted'
});

Per-environment policies #

Each environment has its own ingest policy: sampling rates, retention, payload caps, allowed origins, bot handling, and hard limits. That is what lets production and development behave differently from one app. Configure them under Ingest policies.