---
title: Scale and architect a Synthetics deployment
description: Use these advanced considerations when using the Synthetics app for large and complex use cases. In complex environments it’s common to have multiple...
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6367/solutions/observability/synthetics/scale-architect-synthetics-deployment
products:
  - Elastic Cloud Serverless
  - Elastic Observability
applies_to:
  - Elastic Cloud Serverless: Generally available
  - Elastic Stack: Generally available
---

# Scale and architect a Synthetics deployment
Use these advanced considerations when using the Synthetics app for large and complex use cases.

## Do not use the Synthetics UI with CCS/CCR

<applies-to>
  - Elastic Stack: Generally available
</applies-to>

In complex environments it’s common to have multiple task-specific Elastic Stack deployments with one  centralized overview cluster using CCS or CCR to centralize Kibana dashboards and apps. **Do not use this pattern with the Synthetics UI**. Instead, configure your synthetic monitors directly on the Kibana instance where you want to view and manage them.
You may, however, use Dashboards and the Discover feature with CCS to view `synthetics-*` indices.
The Synthetics UI does *not* work with CCS/CCR because it would limit the rich user experience that the Synthetics UI provides. Unlike the majority of Kibana apps, the Synthetics UI relies heavily on state stored in Kibana shared objects in order to provide a rich user experience. Because Kibana saved objects cannot be shared via CCS/CCR, the Synthetics UI will not show any user data even if CCS/CCR is configured.

## Do not use the Synthetics UI for infrastructure or Kubernetes monitoring

The Synthetics app is designed for active synthetic checks against user-defined URLs and user journeys. **Do not use it for host or pod availability monitoring via autodiscovery** — for example, automatically checking every pod in a Kubernetes cluster as it starts and stops.
The Synthetics UI only shows monitors that are explicitly created and managed through the [Synthetics UI](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6367/solutions/observability/synthetics/create-monitors-ui) or a [Synthetics project](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6367/solutions/observability/synthetics/create-monitors-with-projects). It has no mechanism for dynamic autodiscovery of infrastructure targets, and it is not designed to ingest or display the high volume of short-lived monitor results that infrastructure monitoring typically produces.
For infrastructure or Kubernetes uptime monitoring, use one of the following approaches instead:
- **Heartbeat with autodiscovery**: Run Heartbeat directly on your infrastructure and use its [autodiscovery](https://www.elastic.co/guide/en/beats/heartbeat/current/configuration-autodiscover.html) capabilities to dynamically monitor hosts and pods. Results appear in the [Uptime app](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6367/solutions/observability/uptime).
- **Elastic Agent with the Uptime Monitors integration**: Deploy a standalone Elastic 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.15.


## Manage large numbers of Synthetic monitors with tags

When managing larger numbers of synthetic monitors, use tags to keep them organized. Many of the views in the Synthetics UI are tag-aware and can group data by tag.

## Create custom dashboards

If we don't provide a UI for your exact needs, you can use [dashboards](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6367/explore-analyze/dashboards) to build custom visualizations. For a complete accounting of fields used by the Synthetics UI, refer to [Heartbeat's exported fields](https://docs-v3-preview.elastic.dev/elastic/beats/tree/main/reference/heartbeat/exported-fields).