Skip to content
Platform Signals
Go back
Observability

Building Multi-Region Synthetic Monitoring with Grafana Open Source (For Free)

4 min read

Why synthetic monitoring is expensive because it’s outsourced, not because it’s hard. Here is how to take ownership back.


01. Why synthetic monitoring doesn’t need to be expensive

Most discussions around synthetic monitoring immediately lead to SaaS tools: Datadog, Dynatrace, New Relic — all powerful, all expensive, all usage-based.

But here’s the uncomfortable truth: Synthetic monitoring is not expensive because it’s hard. It’s expensive because it’s usually outsourced.

This is not a “cheap alternative” — it’s an ownership-first design, the kind real SRE teams use.

In this post, I’ll show how to build private, multi-region synthetic monitoring using Grafana Open Source tools, with:


02. The problem with traditional uptime monitoring

Classic monitoring asks: “Is the server responding?” Users ask: “Can I actually use the site?”

These are not the same question. A website can return HTTP 200, have healthy servers, and show green dashboards, yet still be unusable because JavaScript fails, navigation breaks, or only one region is affected. This gap is exactly where synthetic monitoring lives.

What we’re going to build

We’ll build a system that answers one question: “Can a real user complete a real journey from different parts of the world?”

The stack (100% open source):


03. Key idea: regions are where you run, not a feature

This is the most important concept to understand. k6 Open Source does not “have regions.” Regions come from where the test is executed.

If you run the same test from London, Frankfurt, and Mumbai, you have multi-region monitoring — regardless of the tool. This is how the internet actually works.


04. Step 1: Write a real browser synthetic journey

Instead of pinging an endpoint, we test a user journey. Example: open a hub page, click an article, wait like a real user.

// k6-browser-script.js
import { browser } from 'k6/browser';
import { check } from 'k6';

export const options = {
  scenarios: {
    journey: {
      executor: 'shared-iterations',
      vus: 1,
      iterations: 1,
      options: {
        browser: { type: 'chromium' },
      },
    },
  },
  tags: {
    job: 'platformsignals_browser_synthetic',
    instance: __ENV.INSTANCE || 'local',
  },
};

export default async function () {
  const page = await browser.newPage();

  await page.goto(
    'https://www.platformsignals.dev/',
    { waitUntil: 'domcontentloaded' }
  );

  const title = await page.title();
  check(title, {
    'homepage loaded': (t) =>
      t.toLowerCase().includes('platform') ||
      t.toLowerCase().includes('signals'),
  });

  const links = await page.$$eval('a', (as) =>
    as
      .map((a) => a.href)
      .filter((h) => h && h.startsWith('https://www.platformsignals.dev'))
      .slice(0, 3)
  );

  for (const link of links) {
    await page.goto(link, { waitUntil: 'domcontentloaded' });
    await page.waitForTimeout(2000); // simulate reading time
  }

  await page.close();
}

This test doesn’t care about servers. It cares about experience.


05. Step 2: Make it “multi-region”

Here’s the trick that makes everything click. You run the same script, but label where it runs via environment variables:

INSTANCE=uk-london    k6 run browser-platformsignals.js
INSTANCE=eu-frankfurt k6 run browser-platformsignals.js
INSTANCE=ap-mumbai    k6 run browser-platformsignals.js

INSTANCE is just a label. The machine location is the region. The script stays identical everywhere.


06. Visualising & Alerting

Once you emit metrics (optional step), Grafana OSS lets you answer real questions. Is Frankfurt slower than London? Are failures regional or global?

The key benefit isn’t pretty charts — it’s context. A single failure is noise. The same journey failing in two regions is a signal.

Alerting philosophy

The biggest mistake teams make is alerting on every synthetic failure. With browser tests, that’s a recipe for noise.

Do NOT Alert OnDO Alert On
One failed runSame journey failing across regions
One slow pageSustained failure over time
One region blipError budget burn

07. OSS vs SaaS: The Honest Comparison

AspectGrafana OSS ApproachSaaS Synthetics
CostFree / PredictableUsage-based ($$$)
PrivacyFull ControlVendor-managed
RegionsYou decideVendor decides
Learning ValueVery HighLow
Setup EffortHigherLower

The real takeaway

Synthetic monitoring is not about tools. It’s about where you stand and what you observe. If you control the journey and the vantage point, you don’t need to pay to understand reliability.

Grafana Open Source gives you the building blocks. The architecture — and the insight — are up to you.


Share this post:

Previous Post
The Four Golden Signals, Reimagined for AI Systems
Next Post
The Four Layers of Truth: Monitoring Journeys, Not Just Servers