Who it’s for
- SRE/DevOps teams monitoring real user experience (not just synthetic tests)
- Frontend and platform engineers improving page performance
- Product and engineering leaders tracking experience KPIs (e.g., latency, errors, throughput)
- Teams operating multi-region delivery who need route and edge visibility
What RUM is (and what it isn’t)
What RUM is
Real User Monitoring (RUM) is a passive monitoring approach that captures telemetry from real user sessions to show how availability and performance affect users in real conditions (device, network, location, browser).
What RUM isn’t
RUM is not a load test, and it does not simulate traffic. It measures what real users actually experience.
How Edge Pulse works
After you add the Edge Pulse JavaScript tag to a page:
- The browser loads your page normally.
- The tag runs asynchronously and doesn’t block page load.
- Edge Pulse collects real-time metrics about:
- navigation behavior
- availability and latency
- throughput/bandwidth
- network and routing context (anonymized)
- Results are sent to Azion processing servers for analysis and visualization.
Sampling behavior (how it avoids over-testing users)
- Each user is tested against only three Azion edge network addresses at a time
- Tests run in 30-minute intervals per user
- Routes are tested continuously and diversely across possible paths a user can take
Key features
- Real-time collection of availability, latency, and throughput
- Async script that doesn’t interfere with page structure or load process
- Respects HTTP/HTTPS automatically
- Uses UUID4 for efficient success/failure correlation
- Uses browser localStorage for identifier handling (with DNT-aware behavior)
Data collected (high-level)
Edge Pulse collects context such as:
- DNS resolver used
- tested edge location
- user’s anonymous network characteristics
These signals help you:
- decide on routing and delivery strategies
- understand user constraints (network, geography, device patterns)
- identify experience regressions faster
Categories of collected data
- Navigation
- Performance
- User experience
- Informational
- Network
Privacy and “Do Not Track” behavior (navigator.doNotTrack)
| Browser setting | What Edge Pulse does |
|---|---|
navigator.doNotTrack = '1' | If the user has never been tracked (no localStorage identifier exists), a new identifier is generated per visit. If tracking occurred previously, the old identifier is deleted and a new one is generated. |
navigator.doNotTrack <> '1' | Tracking is allowed. The same identifier can be reused across visits for continuity. |
When to use Edge Pulse
Use Edge Pulse when you want to:
- measure real performance across devices, browsers, and networks
- detect availability/latency issues that synthetic monitoring misses
- understand which regions/paths/edges correlate with poor experience
- track experience changes after releases, CDN changes, or routing updates
- prioritize performance work based on actual user impact
When not to use it
Edge Pulse may not be the best fit when you:
- need synthetic checks (scheduled probes) rather than real traffic telemetry
- can’t add any client-side tag due to policy constraints and don’t have an approved alternative
- require user-level identity tracking (RUM is not a user analytics or attribution tool)
- need deep server-side tracing only (RUM complements—doesn’t replace—APM/tracing)
Signals you need this (symptoms)
- “Our uptime is fine, but users still complain the site is slow.”
- Performance varies widely by region, ISP, or device and you can’t explain why.
- You see occasional spikes in latency/throughput but can’t reproduce them in tests.
- You need evidence to decide whether issues are frontend, network, or delivery-path related.
- Release days correlate with complaints, but logs don’t show clear failures.
Metrics and how to measure (what to look at)
Common RUM metrics you should track with Edge Pulse data:
- Availability rate: % of sessions without failures
- Latency: distribution over time (p50/p95/p99) rather than only averages
- Throughput/Bandwidth: trends by region/network to spot delivery bottlenecks
- Navigation timing patterns: regressions after deploys or third-party changes
- Edge/location correlation: identify whether specific delivery paths degrade experience
Tip: prefer percentile-based dashboards (p95/p99) to avoid “average hides the pain.”
Common mistakes (and fixes)
-
Mistake: Installing the tag on only one page.
Fix: Add the tag to every page you want to monitor (templates/layouts are ideal).
-
Mistake: Expecting RUM to replace synthetic checks.
Fix: Use RUM for real-user visibility and synthetic monitoring for constant probes.
-
Mistake: Blocking scripts with CSP and assuming RUM can’t work.
Fix: Use the Pre-loading Tag option when inline JavaScript is restricted.
-
Mistake: Relying on averages only.
Fix: Track percentiles (p95/p99) and segment by region, browser, and network.
Edge Pulse JavaScript tag (how to add it)
To start monitoring, you must insert the Edge Pulse JavaScript tag on each page you want to track.
- The tag is available in the Edge Pulse page in the Azion Console via Copy to Clipboard.
- Execution begins after the browser loads the page (depending on tag type).
- You can publish it manually in HTML or via tag management systems.
Tag options
| Tag | Best for | What it does |
|---|---|---|
| Default Tag | Most sites | Place before </body>. Waits until the page load event completes before downloading/running the RUM client, avoiding interference with user experience. |
| Pre-loading Tag | Strict CSP environments | Place just before </body>. Runs before the load event; useful when inline JavaScript is restricted by Content Security Policy. |
How this applies in practice
Typical RUM workflow:
- Instrument key pages (homepage, login, checkout, core app flows).
- Segment by region, ISP/network, device, and browser.
- Baseline current performance and availability percentiles.
- Detect regressions after releases and infrastructure changes.
- Act: optimize frontend assets, adjust routing, fix origin bottlenecks, or tune edge strategy.
- Validate improvements by comparing percentiles and error rates before/after.
How to implement on Azion (docs)
- First steps: Edge Pulse first steps
- Explore results and workflows via: Real-Time Events
- Product overview: Observe
Integrations
- Works with common tag management systems (publish the tag via your existing tooling)
- Designed to feed analysis via Azion’s Observe ecosystem and Real-Time Events
Limitations (what to plan for)
- Requires adding a client-side JavaScript tag on the pages you want to measure
- Visibility depends on real traffic (low-traffic pages yield slower learning)
- User privacy settings (e.g., Do Not Track) can change identifier behavior
Docs (quick links)
Mini FAQ
What is Edge Pulse used for? To capture real user performance and availability metrics in the browser and use them to improve delivery and user experience.
Is Edge Pulse synthetic monitoring? No. It’s RUM: it measures real traffic from real users rather than scheduled probes.
Do I need to add the tag to every page? Yes—only pages with the tag will be monitored.
Will the tag slow down my page? The script runs asynchronously and is designed not to interfere with page load or structure.
What if my CSP blocks inline scripts? Use the Pre-loading Tag, designed for environments with restrictive Content Security Policy settings.