Real User Monitoring
Real User Monitoring.Real users, real numbers.
fastmon measures web performance right in your visitors' browsers: real devices, real networks, the Core Web Vitals Google ranks you by. No lab, no guesswork, no 28-day averages.
What is RUM?
The performance your visitors actually get.
Real User Monitoring (RUM) measures how your website performs in the browsers of your real visitors, on their own devices and networks, as they experience it. A small script reads the browser's native Performance APIs on every page load and reports the timings back. This is field data, the opposite of a lab test on one fast machine in an office.
That difference is the point. A synthetic tool tells you how fast one simulated device loaded your page under ideal conditions. RUM tells you how fast it was for the visitor on a three-year-old Android on mobile data. It is the truth, noisy and slower, aggregated at the 75th percentile so you see the experience of the users who suffer, not a flattering average.
It is also not web analytics. Analytics counts visits and sources. RUM measures the performance of each visit: the Core Web Vitals Google ranks you by, JavaScript errors, and where the time actually goes. fastmon gives you all of it from one script, without cookies*, hosted entirely in the EU.
Why RUM
See what a lab test never shows you.
Three things field data does that synthetic checks and analytics cannot.
See what real users experience
Every real page load reports its Core Web Vitals, so you see the performance your visitors actually get, segmented by device, network and country, not a single average.
Fix the right thing
p75 percentiles, LCP subparts, request waterfalls and error fingerprints point you at the pages and causes that matter, instead of chasing a lab score.
Get alerted before users complain
Threshold and regression rules on the vitals, routed to email, Slack, Discord or a webhook, with release markers so you know which deploy caused it.
Core Web Vitals
The three metrics Google ranks you by.
fastmon reports LCP, INP and CLS from real visits, aggregated at the p75 against Google's own thresholds. Green means 75% of your visitors were at least this fast.
How fast does the main content appear?
Largest Contentful Paint is the moment the biggest visible element (a hero image, video poster or headline) has rendered. fastmon breaks it into its four subparts, from TTFB to element render delay, so you see where the wait is.
- Good
- ≤ 2.5 s
- Needs work
- ≤ 4.0 s
- Poor
- > 4.0 s
Does the page respond instantly to taps and clicks?
Interaction to Next Paint is the worst-case delay between an interaction and the next frame. It replaced FID as a Core Web Vital in March 2024. Long Animation Frames (over 50 ms) point at the script that blocked the response.
- Good
- ≤ 200 ms
- Needs work
- ≤ 500 ms
- Poor
- > 500 ms
Does the layout jump around while loading?
Cumulative Layout Shift scores how much visible content moves unexpectedly. fastmon reports the worst shift window per visit, so a late-loading banner that pushes your content down does not hide in the average.
- Good
- ≤ 0.1
- Needs work
- ≤ 0.25
- Poor
- > 0.25
One number for the meeting: the Experience Score.
fastmon condenses the vitals plus error rate and load time into a single Experience Score from 0 to 10, graded A+ to F.
Seven weighted signals: LCP 25%, INP, FCP and error rate 15% each, page load time, CLS and TTFB 10% each. Each is mapped to a sub-score by linear interpolation against its good and bad threshold.
Cannot read properties of undefined (reading 'map')
3 visitors affected · first seen 2 h ago · checkout.js:42
Errors & network
Where the time goes, and what breaks.
Slow is one problem, broken is another. fastmon reports both from the same real visits, down to the backend phase and the exact error fingerprint.
- JavaScript errors grouped by fingerprint (type, message, stack shape), with occurrence count, affected visitors and first and last seen
- Error rate over time: the share of pageviews with at least one error, excluding errors from ad-blocked trackers and teardown noise
- Navigation and resource timing, plus fetch and XHR calls at the p75 and p95 with a request waterfall
- Server-Timing breakdown into seven phases across the request path (edge, origin, backend, database, render, cache, external)
- Cache monitoring across browser, CDN and origin layers, including the bfcache hit rate
Segments
Slice it by country, device and page.
An average hides the visitors who suffer. fastmon lets you break every metric down until you find the segment that is actually slow.
- Geography by country, derived from the IP at the edge (the raw IP never reaches the backend)
- Device type, browser, OS, viewport and connection type
- Per-page and per-template, so you see which routes are slow
- Visitor Explorer: individual visits with duration, device and per-page Web Vitals and errors
- Single-page apps: client-side route changes are tracked as soft navigations
Built for production
Alerts, releases and an API.
RUM is only useful if it fits your workflow. fastmon plugs into the tools you already run.
Alerts that route themselves
Rules on LCP, INP, CLS, FCP, TTFB, error rate, pageviews or visitors, absolute or percentage-change, sent to email, Slack, Discord or a webhook.
Release tracking
Tag a deploy with one API call from GitHub Actions, GitLab or Vercel. fastmon compares the vitals before and after at the p75.
REST API with OpenAPI
Query every metric through the Analytics API, with Bearer-token auth, offset and cursor pagination and an OpenAPI schema.
Privacy
Designed inside the GDPR. Not retrofitted to it.
That is the difference between a monitoring tool from the EU and one with an EU region. Here is the data sheet: the honest version, footnote included.
* Refers to the consent requirement under § 25 TDDDG, which presupposes access to the end user's device. A separate consent requirement under the GDPR may apply as soon as personally identifiable data is processed in a specific deployment. Assessing this is the responsibility of the respective website operator embedding fastmon.
Data sheet
- Cookies
- 0*strictly storage-free: no localStorage, no sessionStorage
- IP address
- removed at the edgebefore any application code ever sees it
- Location
- country onlytwo-letter ISO code, nothing more
- Data path
- 100% EUno Cloudflare, no AWS, no GCP
- Retention
- 90 daysdefault, configurable per website
- Fingerprinting
- noneno canvas, no font enumeration
Where it fits
RUM, Synthetic and Analytics.
Three different jobs. fastmon does all three from one script, but they answer different questions.
The performance real visitors get, from the field, at the p75. Answers: how fast is my site, really, and for whom?
Scheduled lab tests on a simulated device under ideal conditions. Reproducible, great for catching regressions before a deploy.
Who visits, from where, through which campaign. Measures traffic, not performance. In fastmon it sits right next to the vitals.
Setup
Live in about five minutes.
One script tag in the head, no build step, no configuration. Works with any stack, from static HTML to Next.js, WordPress and Shopware.
<script defer src="https://fastmon.site/s/{source_hash}.js"></script>
Add the tag
Vanilla JS, ~40 KB compressed, loads with defer.
Verify with a 204
The collector answers 204 No Content. One look at the network tab.
Watch data arrive
Your first visitors show up in the dashboard about a minute later.
FAQ
Real User Monitoring, answered.
The questions people ask before they add the tag.
What is the difference between RUM and synthetic monitoring?
RUM is passive: it measures real visits in real browsers, so it captures the actual experience across every device and network, aggregated at the p75. Synthetic monitoring is active: it runs scheduled tests on a simulated device under ideal, reproducible conditions. They complement each other, and fastmon does both from the same script.
Is RUM just another analytics tool?
No. Analytics counts visits, sources and campaigns. RUM measures the performance of each visit: Core Web Vitals, JavaScript errors and network timing. fastmon shows both side by side, but the RUM data is about speed and stability, not traffic.
Which metrics does fastmon measure?
The three Core Web Vitals (LCP, INP, CLS) at the p75 against Google's thresholds, plus the diagnostics FCP, TTFB and page load time, JavaScript errors, and network timing including Server-Timing phases. Everything condenses into one Experience Score from 0 to 10.
Do I need a cookie banner for RUM?
In most cases yes, but for a different reason than with classic analytics tools. fastmon itself sets no cookies* and, in the default (read-only) mode, stores nothing on the device. The IP address is reduced to a country code at the edge and discarded immediately, query strings are stripped, and there are no long-lived or cross-site identifiers. What remains is read access to browser APIs (the Performance API for Web Vitals, viewport, errors). Under the prevailing interpretation this access falls under § 25 (1) TDDDG and requires consent. The website operator obtains that consent through their consent management platform, exactly as with other tools; the responsibility sits with the operator and is described in our privacy policy (section 5.5). The difference from cookie-based trackers shows at opt-out: if a visitor declines, fastmon measures nothing for that visit, exactly as it should. What does not happen, though: no double-counted users, no orphaned sessions, no distorted unique counts, because fastmon never builds a long-lived or cross-site recognition that could break in the first place. fastmon measures aggregate field performance from a sample, and a smaller sample stays meaningful. So your metrics just get smaller, not skewed, whatever your opt-out rate. With cookie-based tools every opt-out additionally costs you recognition, and with it the reliability of your user numbers.
Where is the data stored?
Entirely in the EU, on infrastructure run in Germany. No Cloudflare, no AWS, no GCP, no US sub-processor anywhere in the data path. Data is retained for 90 days by default, configurable per website.
How fast is the setup and will it slow my site down?
About five minutes: one script tag with defer, no build step. The script is vanilla JS, around 40 KB compressed, and reads the browser's native Performance APIs. Data goes out through navigator.sendBeacon on a deliberately lean wire format, batched across the page lifecycle.
See what your visitors
actually experience.
Core Web Vitals from real devices, read-only by default: no cookies*, no long-lived identifiers. Live in about five minutes.
Light
€29/month
200,000 pageviews included.
Need debugging and all features? Standard from €99 for 1M pageviews. Enterprise on request. See all plans