Website monitoring is the one piece of observability with a genuinely simple question behind it: from where a customer sits, does the thing answer, and how fast? You cannot answer that from inside your own network, because the box doing the asking shares every dependency with the box being asked.
Grafana Cloud's synthetics run the check from their probes instead, and the free tier covers this comfortably. Here is the whole setup, plus the free-tier numbers so you know what you are working inside.
| Resource | Free tier limit |
|---|---|
| Synthetics | 100k API + 10k browser test executions per month |
| Metrics | 10k active series, 14-day retention |
| Logs | 50 GB ingested per month, 14-day retention |
| Traces | 50 GB ingested per month, 14-day retention |
| Profiles | 50 GB ingested per month, 14-day retention |
| Users | 3 active monthly users |
| Grafana Assistant | 3 active AI users per month, 40M tokens per user |
| Support | Community only |
From the Grafana Cloud pricing page, checked 2026-08-28. No credit card required.
For context on whether 100k API executions is a lot: a single check running every minute from three probes uses roughly 130,000 executions a month, so it is not unlimited. At every ten minutes from three probes you are around 13,000 - about a tenth of the allowance, leaving room for several sites. Frequency and probe count multiply, and that is the number to watch.
The 14-day retention is the other real constraint. It is fine for "is it up" and useless for "was this slower than last quarter". If you need historical comparison, that is the thing that pushes you off the free tier, not the check volume.
Navigate to Testing and synthetics → Synthetics and create a check. The type you pick sets what you can assert:
| Check type | Use for |
|---|---|
| API endpoint | A single URL or API route. Cheapest and simplest. |
| Multi-step | Several URLs in one check - homepage, services, about. The right default for a site. |
| Browser | A real browser, so client-side rendering and JavaScript-dependent content are actually exercised. Counts against the smaller 10k browser allowance. |
| Scripted / k6 | Custom logic, logins, multi-stage journeys. |
Multi-step is usually the right answer for a site, because it catches the common real failure: the homepage is served from cache and looks fine while an inner route returns 500. Add a request per URL you care about.
If your site is a single-page app, API checks lie to you. They fetch HTML and get a 200 for a shell that renders an error once JavaScript runs. That is what the browser check type is for, and it is worth spending part of the 10k allowance on your most important route.
Pick several, on different continents. This is not a nice-to-have - a check from one location tells you that one network path works, and the failures worth catching are usually regional: a CDN edge misbehaving, a DNS change that has not propagated, a route that is fine from Europe and broken from Asia.
Three widely separated probes is a sensible default. If you have traffic concentrated somewhere, put one there. Private probes are available if you need to check something that is not publicly reachable.
Set the frequency with the execution budget in mind - every ten minutes is plenty for a site whose outages you would measure in minutes, and it leaves headroom.
Configure it while you are here, because a check with no alert is a dashboard you will not be looking at when it matters. The built-in option - alert if at least one execution fails within a window - is the right shape to start with.
"At least one" across several probes is deliberately sensitive: a single probe failing is often the probe's network rather than your site. Start sensitive, see what the noise actually looks like over a week, and tighten to "more than one probe" if you are getting woken by transient regional blips. Tuning against real data beats guessing at thresholds up front.
A running check gives you uptime, reachability, average latency, per-probe logs and error rates - but as a check result view, not a dashboard. Building the dashboard by hand means learning the panel types and the query language, which is a real afternoon if Grafana is not somewhere you live.
The Grafana Assistant - the sparkle icon, top right - will do it. Ask it in plain language to create a dashboard for the check and it builds one, iterating on its own output when a panel comes out badly.
It also takes corrections, which is where it stops being a novelty. A concrete example worth copying: the generated HTTP duration panel legend showed only probe names, so several lines per probe - one per redirect step - were indistinguishable. Describing the problem in a sentence was enough; the Assistant identified that the metric carried a URL label and rewrote the legend to probe plus URL.
Read what it built. The output is a real dashboard with real queries, and it is worth opening a panel to see how it was done - it is a reasonable way to learn the query patterns. It is also the only way to notice if a panel is showing something subtly other than what you assumed.
The Assistant's own limits and the privacy question on the self-hosted path are covered separately.
Synthetics tell you the front door answers, from outside, at intervals. They will not tell you why it stopped, they will not catch a failure that heals between checks, and a ten-minute interval means up to ten minutes of unnoticed downtime.
That is the right trade for what it costs, and it is genuinely the highest-value monitoring you can add to a site in ten minutes. Just do not mistake a green uptime panel for knowing your application is healthy - it is the smoke test, not the diagnosis.
Ten minutes from a fresh free account to a working dashboard, including the part where the Assistant fixes its own legend.
Synthetics tell you the front door answers. They say nothing about why it stopped, which is where the rest of an observability stack earns its keep. If you are working out where Grafana Cloud ends and something self-hosted begins, or joining synthetics up with infrastructure monitoring you already run, that is worth a conversation.