JavaScript error tracking is on by default and shares a dataset with traffic. Errors are grouped by type, message, file, and line, with browser-extension noise filtered out. Track a conversion with one line, cronitor('track', 'Checkout'). Both rates are measured per session, so you can see whether errors and lost conversions move together — without a goal builder, second SDK, or tag manager.
site.error_rate > 0.5% over 5 minutes — routed to the same on-call as a failed check.A lab test measures one machine, on one connection, at one moment. Cronitor measures the browsers that actually loaded your page — Largest Contentful Paint, Cumulative Layout Shift and the full page-load timing — and reports them at the median, the 95th and the 99th percentile. Every pageview is recorded unless you turn sampling down yourself.
Cronitor records eight timings for every page load and groups them into three stages. Backend covers your origin, network covers the trip to the visitor, and frontend covers the browser and your JavaScript. The breakdown shows where to start instead of handing you one total load time.
site.loadtime.p95 > 2.5s over 1 hour./checkout behaves nothing like /.The script sets no cookies, and Cronitor does not store visitor IP addresses. Sessions cannot be traced back to individual visitors, including by us. Filters run before data is stored: crawlers and localhost are dropped by default, and you can also exclude IP ranges, countries, or path prefixes.
A lab test runs your page on one controlled device and connection. That makes the result repeatable and useful, but it does not show what happened to a visitor on a mid-range phone and a congested mobile network far from your origin.
Real user monitoring reports what visitors' browsers measured — when the main content appeared, how much the layout moved, where time was spent, and whether JavaScript failed. The results describe your actual traffic rather than a reference device.
Field data also has a limit: it exists only after real people have loaded the change. A low-traffic site takes longer to build a useful distribution, and visitors experience a regression before it appears in the data. Synthetic monitoring covers that gap, which is why the two approaches work best together.
One async script in your <head>. It reports a pageview, the page-load timings, the web vitals and any JavaScript error, from every browser that loads the page. Client-side route changes are tracked automatically, so a single-page app needs no additional wiring.
Cronitor loads the page itself, on a schedule, from the regions you pick, and asserts against the response. Identical conditions every run, so a change in the number is a change in your site.
It can run before the release reaches anybody. It cannot tell you what your visitors got. → Checks
Real browsers report what real visitors measured, on the devices, networks and geographies they actually have. The distribution is your audience, not a reference machine.
It cannot run before release, and it needs traffic to mean anything. → Analytics
The two failure modes are different too. A check catches the page that stopped answering; analytics catches the page that still answers, still returns 200, and has quietly stopped converting.
Sessions, pageviews, bounce rate, average session duration and events per session, in real time. Referrers by hostname and the complete UTM set — source, medium, campaign, content and term — so paid and organic acquisition are separable. Every query can carry compare: previous_time_range, which returns the prior period's value and the change rate alongside the current one.
Largest Contentful Paint and Cumulative Layout Shift at p50, p95 and p99, and page load time at seven percentiles from p10 to p99. Read any of them per path, per country, per device type or per connection type — the numbers for /checkout on mobile 4G are the ones that matter, and they are not the numbers on your laptop.
Group or filter by any of the sixteen dimensions, with eq, ne, gt, gte, lt, lte, startsWith, endsWith or contains — ten filters at a time, combined with AND or OR. Aggregations, breakdowns, time series and error groups all come out of one query endpoint, bucketed by minute, hour, day, week or month, in the timezone you asked for.
Five things you can assert on: pageviews, sessions, page load time at a percentile, error count and session error rate — each against a threshold over a window you choose. A site alert is a monitor like any other, so it shares the dashboard, the escalation rules and the ten-plus notification integrations with your checks, jobs and heartbeats.
Track traffic, performance, conversions, and JavaScript errors without tracking cookies or adding a tag manager.
Sessions, pageviews, bounce rate and session duration, updated as visitors arrive.
Largest Contentful Paint and Cumulative Layout Shift, measured in your visitors' browsers.
Eight timings per load, rolled up into backend, network and frontend stages.
On by default. Grouped by type, message, file and line, with extension noise filtered out.
One call, cronitor('track', 'Signup'), and conversion rate updates in real time.
Sixteen dimensions, nine filter operators, combined with AND or OR.
One snippet across several domains, with sessions stitched instead of double-counted.
Tag traffic as production, staging or anything else, and switch the whole dashboard.
Drop bots, localhost, IP ranges, countries or path prefixes before anything is stored.
Assert on traffic, load time or error rate, and route it like every other monitor.
Aggregations, breakdowns, time series and error groups, with period-over-period built in.
Analytics shows when a page gets slow for real visitors. Checks watch the endpoint behind it, jobs watch the scheduled work that refreshes its data, and heartbeats watch the worker. They all share one account, dashboard, and alert pipeline.