Monitors

A monitor checks one target on a schedule, from the locations you pick, and alerts when the check keeps failing. Monitors are listed under Synthetics → Monitors.

---

Monitors List

• The state strip above the table filters by state with one click.
• The search bar filters by status, type, location, probe, owner, enabled, tag_policy and any label key; plain text searches names.
• The filter panel on the left offers the same filters as facets: Status, Type, Location, Probe, Team, Env, Service, Owner, Enabled, Tag policy and other labels.

Click a row to open the monitor's details.

Row and bulk actions

Each row's menu has Edit, Duplicate, Run now, Pause / Resume and Delete. Deleting a monitor also removes its results and outages.

Select rows to get the bulk bar: Run now, Pause, Resume, Add to maintenance window, Export CSV, Export selected (YAML or JSON) and Delete. Monitors you can only view are skipped by run, pause, resume and delete.

Export

Export above the table exports every monitor that matches the filters:

• Export as YAML — SyntheticMonitor resources, ready for kubectl apply or for import.
• Export as JSON — the API representation.
• Download CSV — the table's columns for the selected time range.

Secrets are exported as {{ secret:<name>/<key> }} placeholders, never as values.

---

Creating a Monitor

Click Create Monitor. Pick how to start:

The editor has six steps. Next checks the current step; you can go back to any step at any time.

Step 1 — Define

If a tag policy is set, a banner lists the required or recommended tags.

Step 2 — Request (or Steps)

The type's settings: the HTTP method, headers, body and authentication, the DNS record type, the TCP port, and so on. For multistep and browser tests the step is called Steps and holds the test's steps. Every field is described in Check Types.

Fields accept variables as {{ NAME }}, for example Authorization: Bearer {{ API_TOKEN }}.

Step 3 — Assertions

Every assertion must pass for a run to succeed. Click Add assertion and pick what to check (status code, response time, body, header, certificate and so on, depending on the type), an operator and the expected value.

For a response body, pick JSONPath, XPath or JSON Schema to check part of it. When a path selects several values, choose whether the first value, every value or at least one value must match. For HTTP, Suggest assertions proposes assertions from a live response.

Test <type> → Run test runs the check once from the API server without saving, so you can see the response while you write assertions.

Step 4 — Locations & schedule

Step 5 — Alerting

How alerts are created and delivered is described in Alerts & Maintenance.

Step 6 — Review & test

A summary of the monitor (for example Every 1m from 2 locations · 24/7 · alerts after 3 failures to Slack), with an Edit link per section. When editing, Changes lists every field you changed.

Test before saving → Run test runs the monitor once from the API server, without saving. Click Create monitor (or Save changes).

---

Editing, Duplicating and Deleting

• Edit opens the same steps; Skip to review jumps to the summary. Every save records a version in the monitor's History tab, from which an earlier version can be restored.
• Duplicate opens a copy named Copy of …, with the original's secrets.
• Pause stops runs and alerts without deleting anything; Resume starts them again.
• Delete removes the monitor, its results and its outages.

Monitors created from a SyntheticMonitor Kubernetes resource carry a GitOps badge. Change them in the resource; their access follows Kubernetes RBAC.

---

Import Monitors

Click Create Monitor → Import from YAML, JSON or Terraform, or Import monitors on an empty list.

1. Upload files (.yaml, .yml, .json, .tf) or paste their content. The format is detected:
   • Kubernetes YAML or JSON — a KubeSense export (kind: SyntheticMonitor);
   • Terraform — kubesense_synthetics_monitor resources;
   • Datadog Terraform — datadog_synthetics_test tests and datadog_synthetics_global_variable variables (the variables are created too).
2. Choose what happens If a monitor already exists: Report an error, Skip it or Replace it.
3. Optionally, Copy secrets from an existing monitor, and map Secret placeholders → global variables.
4. Click Validate. Nothing is written yet: the result lists what would be created, updated or skipped, and any issues.
5. Click Import.

Imported monitors are managed from the web app and API. To manage monitors as code instead, apply the YAML with kubectl or the Terraform with the KubeSense provider.

---

Access

Each monitor has an owner. Editors can open Access on a monitor to set what everyone else gets — No access, Viewer or Editor — and to transfer ownership. A viewer can see the monitor and its results but not run, change or delete it.

Roles control the rest: Synthetics (monitors, suites, results, alerts, maintenance windows), Synthetics locations, Synthetics variables and Synthetics settings each have their own read and write permissions (see Role Access). Without write permission, the buttons that change things are disabled, while viewing and exporting still work.