Three regions, three Kibanas, one view: Cross-cluster search comes to Elastic Synthetics

Keep the data you need and pay for what it’s worth. LogsDB, data tiers, and ILM help optimize storage and retention. Start a free cloud trial.

Until now, three regional deployments meant three browser tabs, separate sets of credentials, and different mental models to reconcile every time someone asked how checkout was doing worldwide. Cross-cluster search (CCS) for synthetic monitoring ships in Elastic Stack 9.5. Monitors from every connected cluster appear in one Kibana, with status, journey waterfalls, screenshots, errors, and certificates. Nothing is replicated; the central cluster expands the index expression at query time and asks each remote directly, so configuration stays where it was created and each cluster still owns its monitors.

This feature is available in stateful deployments only and isn’t supported on Elastic Cloud Serverless.

What cross-cluster search for synthetic monitoring adds to Elasticsearch CCS

Before 9.5, Synthetics and CCS weren't integrated. Connecting clusters at the Elasticsearch layer gave you raw ping data in Discover but not in the Synthetics UI. Elastic's site reliability engineering (SRE) team wrote about this pattern, using CCS to build a single pane of glass across 150+ clusters, but it applied to raw data, not the Synthetics app.

Monitor definitions are Kibana saved objects, and those objects don't travel across clusters. Wiring CCS at the Elasticsearch layer didn't make remote monitors appear in the Synthetics app. You'd get raw data in Discover, but none of the Synthetics UI experience: no status cards, journey waterfalls, step screenshots, or error drilldowns.

That's still true for raw CCS on saved objects. What shipped in 9.5 is a native integration built on top of remote cluster search. The app searches remote synthetics-* pings. It marks what's remote and sends you back to the origin Kibana whenever you need to change something.

What remote monitors look like in the Synthetics UI

Once remote clusters are configured, their monitors appear alongside your local ones throughout the Synthetics UI.

Find remote monitors on the Overview page

The Overview page shows remote monitors inline with local ones, tagged with a Remote badge next to the monitor type badge. Two additions help with navigation: a Remote cluster filter alongside the existing Type / Location / Tags / Frequency filters, and a Group by → Remote cluster option. When a remote cluster filter is active, local monitors are hidden and status counts reflect only the filtered set, so you can focus on one deployment at a time.

Open a remote monitor detail page

Monitor detail pages work the same way for remote monitors as for local ones, including overview, history, errors, journey runs, step details, screenshots, network waterfalls, and duration charts.

A Remote monitor callout shows the cluster name and the originating Kibana URL, and a View on remote cluster button takes you directly to the monitor on its home instance.

See remote TLS certificates on the Certificates page

Transport Layer Security (TLS) certificates observed on remote clusters appear on the Certificates page, with a tooltip showing which cluster they came from.

Can you edit remote monitors from the central Kibana?

No, not from the central Kibana. Remote monitors are read-only where you view them because their configuration lives as a saved object in the Kibana where they were defined.

 To manage a remote monitor, click the View on remote cluster button on its detail page. It takes you to the monitor on the Kibana where it lives.

Keeping configuration on the origin cluster is intentional. A single source of truth for monitor definitions avoids the mess of cross-cluster writes.

One current limitation to note: alerting doesn't cross cluster boundaries yet. A remote monitor that's down shows as down in the federated UI, but it won't fire alerts in the central Kibana. Keep those rules on the cluster that owns the monitor. Federated alerting is on the roadmap.

How to set up cross-cluster search for synthetic monitoring

There are a few things to put in place.

1. Connect the remote clusters in Elasticsearch

In Stack Management → Remote Clusters, add the Elasticsearch clusters that hold Synthetics data. Synthetics doesn't create these connections; it uses the ones already configured at the Elasticsearch level. The Search and replicate data between Elastic Cloud and on-prem post covers the Elasticsearch-level setup in detail.

2. Set server.publicBaseUrl on every participating Kibana

The View on remote cluster deep link comes from a kibanaUrl field on ping documents, stamped from server.publicBaseUrl. If that setting is missing on a remote Kibana, you still see the monitor but there's no URL to click. Since kibanaUrl is written at ping time, you need to wait for new check results after setting this config before the link appears.

3. Choose which remote clusters Synthetics includes

Go to Synthetics → Settings → Remote Clusters. You need the All privilege for Synthetics and Uptime. Users with Read see the form as read-only.

Toggle on Use all remote clusters, or pick specific ones. Each option shows connected versus disconnected status.

4. Grant access to Kibana spaces

This is one shared configuration per deployment, not a separate copy per space. Use the Spaces field to grant access to specific spaces, or select All spaces. On first save, settings are anchored to the space you're in.

Note that clearing the Spaces field on a subsequent save doesn’t remove access from existing spaces. You must explicitly select the spaces you want to keep.

Open the Monitors overview, and remote monitors appear alongside your local ones.

How the index expression resolves across clusters

Nothing is replicated into the central cluster. CCS works by expanding the index expression at query time, which means that the central cluster never stores remote data; it just knows where to ask.

On each request, the server figures out which index expressions to query.

• If you select Use all remote clusters, it builds synthetics-*,*:synthetics-* with no connectivity check needed.

• If you pick specific clusters, it calls Elasticsearch's cluster.remoteInfo() to check which are currently reachable and only includes those, so a disconnected remote doesn't hang your overview page.

• The resolved indices are cached per space.

The result is a combined index pattern like the following:

synthetics-*,cluster1:synthetics-*,cluster2:synthetics-*

The Overview status page and the Certificates page pick up CCS automatically, since they fan out across all configured clusters. Detail views scope each query to the right cluster. Pings, journeys, screenshots, and network events all resolve against a single remote rather than spreading across everything.

What cross-cluster search for Synthetics does not do

CCS for Synthetics is a visibility layer, not a management layer. You get a unified read view across clusters; each cluster stays the owner of its own monitors. If you need to create, edit, or disable monitors centrally, you still do that on the Kibana where each monitor lives.

CCS at the Elasticsearch level is also a prerequisite rather than the whole story. Synthetics needs its own Remote Clusters configuration to show remote monitors properly. Dashboards and Discover can still query synthetics-* via CCS for custom visualizations.

Start centralized monitoring across your clusters

Federated Synthetics ships in 9.5 for stateful deployments. If you run monitors across multiple clusters, go to Synthetics → Settings → Remote Clusters and connect your remotes.

If a remote monitor appears but the deep link is missing, set server.publicBaseUrl on the origin Kibana and wait for new check results. The kibanaUrl field is stamped on documents written after that config is in place.

We welcome your feedback in the Elastic discuss forum.

Documentation:

• Configure Synthetics settings

• Analyze data from synthetic monitors

Related reading:

• Use Cross Cluster Search with Elastic Cloud to improve observability: Elastic's SRE team on building a single pane of glass across 150+ clusters

• Search and replicate data between Elastic Cloud and on-prem: CCS/cross-cluster replication (CCR) general availability (GA) announcement