[Synthetics] Update infrastructure monitoring for k8s

[alaudazzi]

Summary

• Add a short "Not for infrastructure or Kubernetes monitoring" note/admonition to solutions/observability/synthetics/index.md. State clearly that the Synthetics app is designed for active synthetic checks of URLs and user journeys, not for host/pod availability monitoring via autodiscovery. Link to the Heartbeat / Elastic Agent alternatives.

• Add a matching section to solutions/observability/synthetics/scale-architect-synthetics-deployment.md (alongside the existing CCS/CCR "do not use" section) documenting the k8s infra monitoring limitation and recommended alternatives.

Note for reviewers

@emilioalvap @eedugon can you confirm whether the recommended alternatives to document are correct:

For infrastructure or {{k8s}} uptime monitoring, use one of the following approaches instead:

• {{heartbeat}} with autodiscovery: Run {{heartbeat}} directly on your infrastructure and use its autodiscovery capabilities to dynamically monitor hosts and pods. Results appear in the {{uptime-app}}.
• {{agent}} with the Uptime Monitors integration: Deploy a standalone {{agent}} and configure the Uptime Monitors ({{heartbeat}}) integration to collect availability data from your infrastructure. Note that the Uptime app is deprecated as of 8.

The Uptime app (/solutions/observability/uptime/) is deprecated as of 8.15 and should not be promoted as the primary destination. I added a note about deprecation.

Closes #1879.

Generative AI disclosure

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

• Yes
• No

[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: queued.

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/index.md
• solutions/observability/synthetics/scale-architect-synthetics-deployment.md

[github-actions]

✅ Vale Linting Results

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.

[github-actions]

Docs review summary

Focus areas

• Style and clarity: Vale reported no findings (files were outside the default docs/ scope path). Manual review found minor issues — "Note that" filler and "via" where the style guide prefers "through".
• Jargon: {{heartbeat}}, {{agent}}, {{uptime-app}}, {{k8s}}, {{synthetics-app}} are all substitution variables; no unexplained jargon introduced.
• Frontmatter and applies_to: Frontmatter is unchanged. The new section in scale-architect-synthetics-deployment.md correctly omits a section-level applies_to override (the CCS/CCR section above it has stack: ga because it's stateful-only; the new k8s section applies to both stack and serverless, matching the file-level frontmatter).
• Content type fit: Both additions fit their context — an important admonition in the index page and a parallel "Do not use" section in the scale/architect page, consistent with the existing CCS/CCR section pattern.
• Parent issue satisfaction: Closes #1879. The PR adds the requested admonition to the index and a matching section to the scale/architect doc. Satisfied.

Nits

• Both changed files use via where the style guide prefers through (e.g., "monitoring via autodiscovery" → "monitoring through autodiscovery").
• "Note that" appears in both bullets recommending the Uptime Monitors integration — inline suggestions posted above.

Notes

• The pre-fetched Vale data shows eligible_count: 0 because the default scope is docs-subtree (docs/), and these files live under solutions/. Review was performed manually as this repo's docs span the full repository.
• The PR body already flags the Uptime app deprecation tension: both new sections link to the Uptime app while noting it's deprecated as of 8.15. Authors should confirm with @eedugon / @emilioalvap whether a non-deprecated landing page exists, or whether the link should be dropped entirely from the alternatives list.

Generated by Docs review agent for issue #6367 · ● 301.4K

[eedugon]

LGTM! I've suggested some small changes to make the note shorter, plus fixed some links.
Also the elastic agent suggestion links to autodiscover doc.

[florent-leborgne]

I strongly disagree that we should start any overview page of a major feature with a succession of big notes on what the capability is "NOT" for. Please consider the following alternatives:

• Start the page with regular text defining what Synthetics is, is for, and does. This is healthier, better for introducing the feature and tell its user value, and it opens the path to a smaller note further down, a decision paragraph (preferred IMO), or even a specific page, about "When to use Synthetics", including alternatives for cases such as the one described in the important note there.

• Side comment: we can turn the 1st note on the page into regular text too

[alaudazzi]

@florent-leborgne

I strongly disagree that we should start any overview page of a major feature with a succession of big notes on what the capability is "NOT" for. Please consider the following alternatives:

I strongly agree :)
Removed the Note and reworded the text more user-focused.

[emilioalvap]

LGTM

[florent-leborgne]

I think this is still too high/prominent for what it tells but it's in a better shape. We can merge this one and maybe plan a follow up to have a clearer decision making section instead of the admonition?