Document Synthetics multispace CCS settings

[alexandra5000]

Summary

• Adds a new Remote clusters section to the Synthetics settings page documenting the multispace CCS settings UI introduced in Kibana 9.5 (elastic/kibana#269250)
• Adds a complementary section to the scale-and-architect page clarifying that the new native CCS integration (9.5+) is distinct from the CCS/CCR Kibana federation anti-pattern
• Pre-existing style, applies_to, and frontmatter issues fixed across both files

Resolves: https://github.com/elastic/docs-content-internal/issues/1492

Generative AI disclosure

Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

If you answered Yes to the previous question, please specify the tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).
Tool(s) and model(s) used: Claude Opus 4.8

[github-actions]

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

• Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

[github-actions]

🔍 Preview links for changed docs

• solutions/observability/synthetics/configure-settings.md
• solutions/observability/synthetics/scale-architect-synthetics-deployment.md

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[florent-leborgne]

I think this sentence relates to the last subsection here but it's not super clear to me what it means. Is it: "You can apply these settings to other {{kib}} spaces." or "These settings only apply to the default space by default, but you can specify other spaces to share that configuration across them"? or something else.

[alexandra5000]

There is one CCS settings document per deployment. The combo box where you choose spaces controls which Kibana spaces can see that one shared configuration (and, therefore, the config applies to them). I rephrased it for clarity.

[mgiota]

Regarding your rephrased version looks mostly correct, but I left some feedback about deployment-wide wording. I understand how you mean it, but this could read as "applies to the whole deployment", which is not true by default. The settings only apply in the spaces you grant access to, a space without access sees the defaults (CCS off). I left a comment with my suggestion.

[florent-leborgne]

"individual spaces" (plural) / "multiple spaces" means the same thing. From what I see you either pick spaces individually, or select All spaces.

I'm not clear about the "removing..." part. Are the settings actually hidden (for me hidden means you can't configure it there anymore)? Or does that space just get to keep its own individual ccs configuration, not shared?

[alexandra5000]

There are three intended modes: single space, multiple spaces, or all spaces. But you're right in that the UI implements all three through one combo box (you just pick how many spaces). I changed the phrasing to a more accurate one.

[florent-leborgne]

So we shouldn't even have the current space listed?

[alexandra5000]

It means if you select nothing, whatever was selected before is still seeing the shared config. It does not mean that the config is now not being used in any space. This is counter-intuitive, so I made it a note and rephrased it for clarity.

[mgiota]

I agree that the copy Leave empty to keep the current sharing configuration. was the root of the confusion. The field is a pre-filled multi-select, yet an empty selection is silently treated as "no change" (to keep the settings object in at least one space). You'd expect that emptying the list and saving removes all spaces. Instead, an empty list means "don't change anything" — which is surprising, so the help text exists to explain it.

The docs note now documents this accurately, so no change is needed here —I've filed a follow-up to fix it at the source — elastic/kibana#281577: require at least one space (validate/disable Save when empty) instead of treating empty as a no-op. Once it ships, the docs can drop the empty-save explanation so UI and docs stay aligned.

[florent-leborgne]

You added another section below but the difference is not made super clear. Maybe it would help to also add a reference to the actual integrated feature in here. Like "Do not use this pattern xxx, but instead use yyy". Or maybe combine these 2 into a single section that makes sense of the overall remote cluster + Synthetics story and recommendations.

[alexandra5000]

I added a reference at the bottom of the "Do not use" section pointing 9.5+ users to the native CCS feature. For now I kept them as separate sections since they have different applies_to scopes.

[mgiota]

I agree that the difference is not made super clear. I would even rename the section and have one coherent CCS story, starting with what users can do and finishing with what they shouldn't do.

[mgiota]

Now that the built-in CCS integration exists (9.5+), the old "don't use the Synthetics UI with CCS/CCR" guidance is misleading, so I've collapsed the two sections into one. It leads with the supported feature, makes clear the remote view is read-only, and points users to manage monitors on the remote {{kib}} directly.

Suggested change

	## Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}} [synthetics-no-ccs-ccr]
	## View monitor data from remote clusters [synthetics-ccs-settings]
	{applies_to}`stack: ga 9.5+`
	Before 9.5, the Synthetics UI couldn't display data from remote clusters through {{ccs-init}}/{{ccr-init}}, so this setup was discouraged — that's no longer the case. Synthetics now includes a built-in {{ccs}} integration that lets you view monitor data from remote {{es}} clusters alongside your local monitors, directly in the Synthetics UI.
	This view is **read-only**: the integration queries each remote cluster's `synthetics-*` data indices at query time, but monitor definitions and settings stay as saved objects on the {{kib}} where they were created (saved objects aren't shared across clusters). To create, edit, or delete those monitors, manage them directly in the Synthetics UI on the remote {{kib}}.
	To enable it, go to **{{synthetics-app}} → Settings → Remote clusters**. You can select which remote clusters to query and which {{kib}} spaces the settings apply to. Refer to [Remote clusters](/solutions/observability/synthetics/configure-settings.md#synthetics-settings-remote-clusters) for details.

[alexandra5000]

@mgiota Could you help with this? Is it available for every user? I'm not sure

[mgiota]

Editing these settings requires the All privilege for the Synthetics and Uptime feature (Stack Management -> Roles -> Kibana privileges -> Observability). It's the same privilege that controls editing all other Synthetics settings. Users with only Read see the form as read-only. It's not available to every user by default.

[alexandra5000]

@mgiota What are the default settings? Maybe it's worth mentioning.

[mgiota]

Cross-cluster search is off by default. So until you configure it, only local monitors appear.

Space scope on first save: the settings are anchored to the space you're currently in when you first save. You can use the Spaces field to extend access to other spaces.

Default space

Space b

[mgiota]

the Synthetics UI doesn't show any user data even if you configure {{ccs-init}}.

This is not true. As of 9.5, you can view monitor data from remote clusters directly in the Synthetics UI using the dedicated Remote clusters feature. It reads remote monitor data over {{ccs-init}} and shows it read-only alongside your local monitors. You cannot manage remote monitors from that view, though. (Implementation in this Epic)

[mgiota]

I am reading now the new section you added right below that explains the CCS integration, so we are good here.

But still we need to correct the sentence that says the Synthetics UI doesn't show any user data even if you configure CCS (implementation detail, we don't get remote monitors data from a Saved Object, we can't anyway, that's a local thing, but we get it from the monitor's ping data instead)

[mgiota]

Instead of and I suggest we use or:

Use the "Use all remote clusters" toggle or "Select remote clusters" combo box

[mgiota]

Suggested change

	These are deployment-wide settings stored as a single shared configuration. You control which {{kib}} spaces have access to them using the **Spaces** field.
	These settings are stored as a single shared configuration — one per deployment, not a separate copy per space. Use the Spaces field to control which {{kib}} spaces it applies to.

[mgiota]

That's not true. It works because it reads ping data, not saved objects.

Suggested change

	Synthetics supports a dedicated {{ccs}} integration that lets you include monitor data from remote {{es}} clusters alongside your local monitors. Unlike the {{ccs-init}}/{{ccr-init}} federation pattern described in [Do not use the Synthetics UI with {{ccs-init}}/{{ccr-init}}](#synthetics-no-ccs-ccr), this is a native Synthetics feature that works with {{kib}} saved objects and the Synthetics UI.
	Synthetics supports a dedicated {{ccs}} integration that lets you include monitor data from remote {{es}} clusters alongside your local monitors. This is a native Synthetics feature that reads ping data

[mgiota]

Suggested change

	The **Spaces** field shows the current sharing configuration when you open the tab. Clearing the field and saving leaves that configuration unchanged, meaning it does not remove access from existing spaces. To update which spaces have access, select the new spaces explicitly.
	The **Spaces** field shows the current sharing configuration when you open the tab — your current space by default. Clearing the field and saving leaves that configuration unchanged, meaning it does not remove access from existing spaces. To update which spaces have access, select the new spaces explicitly.