Skip to main content

Beats

Beats are StatiBeat's synthetic monitoring workspace. They let page admins check customer-facing paths proactively, capture evidence, and turn those signals into internal alerts, reviewable drafts, or automated public incident updates.

tip

Beats are most useful when they are tied to the same hierarchy and communication model your customers already see on the status page.

This guide is based on:

  • application/frontend/src/pages/admin/SyntheticMonitorManagement.jsx
  • application/frontend/src/constants/presetVariables.js
  • application/frontend/src/services/api.js
  • application/backend/internal/models/synthetic_monitor_models.go
  • application/backend/docs/openapi_public.json

What the Beats workspace covers​

The current page-admin Beats area supports:

  • listing all beats for the selected page
  • creating, editing, enabling, disabling, and deleting beats
  • viewing current stage, recent evidence, and pending reviews
  • manually running a beat immediately
  • reviewing recent runs and generated actions
  • approving or rejecting pending public-facing actions

The same workspace also auto-initializes the shared synthetics runtime for the page when it is not already configured.

Supported beat types​

The current UI supports these beat types:

  • HTTP
  • API
  • Latency
  • Heartbeat
  • Browser Journey
  • TCP Connect
  • DNS Resolve
  • SSL / Certificate Check
  • ICMP Ping
  • Packet Loss
  • Generic (Advanced)

Each beat runs in one or more configured regions. In the current shared runtime, the UI exposes a shared Europe West 2 region for this page.

Basics and target configuration​

Every beat currently includes:

  • name
  • type
  • interval in seconds
  • timeout in milliseconds
  • optional description
  • region selection
  • enabled or disabled state
  • associated hierarchy components

Target configuration depends on the beat type:

  • HTTP, API, Latency, and Heartbeat beats support URL, method, expected status codes, request headers, and optional response-body checks
  • Browser Journey beats support a start URL, ordered browser steps, and shared request headers
  • TCP, DNS, SSL, ICMP, Packet Loss, and Generic beats support protocol-specific targets such as tcp://host:port, hostnames, or TLS endpoints

The component selector matters because automated actions raised by a beat affect the hierarchy items you attach there.

Threshold stages and automation​

Beats use three operational stages:

  • warning
  • critical
  • recovery

The available trigger types depend on the beat type, but the current UI supports rules such as:

  • response time threshold
  • failures in a row
  • failures in a recent rolling window
  • failure duration
  • certificate expiry for SSL beats
  • packet loss for packet-loss beats
  • successes in a row for recovery

For each stage, the current action policy system can send or create:

  • Slack notifications
  • email notifications
  • admin-banner signals
  • public incident drafts or auto-posts
  • automatic critical escalations and recovery resolutions

Where supported, a stage can also attach:

  • browser screenshots
  • MTR network path reports

Messages and variables​

Beats use the same preset-message system as incidents and maintenance, but with synthetic-specific categories:

  • synthetic_warning
  • synthetic_critical
  • synthetic_recovery

The current message system supports stage-specific templates for:

  • warning notifications
  • critical open messages
  • critical follow-up messages
  • recovery messages

Beat actions can render variables such as:

  • {{Monitor-Name}}
  • {{Monitor-Stage}}
  • {{Evidence-Summary}}
  • {{Latest-Latency-Ms}}
  • {{Latest-Status-Code}}
  • {{Latest-Region}}
  • {{Target-Url}}

The current automation UI also lets admins set:

  • predefined customer impact text
  • customer-facing incident status for automated opens
  • whether a public action stays draft-only or posts automatically

Review, evidence, and operator controls​

The current workspace includes three important operational loops:

  1. pending public actions
  2. recent runs and evidence
  3. pause or mute controls

Pending public actions can be reviewed with a title, message, and decision note before approval or rejection.

Recent run evidence can include:

  • observed region
  • stage and summary
  • latency and status code
  • browser journey steps
  • captured screenshots
  • MTR reports
  • TLS certificate details

Operators can also:

  • pause automation with a reason
  • mute notifications until a chosen time
  • resume automation later
  • run a beat immediately without waiting for the next interval

Plan and limit behavior​

The Beats screen is feature-gated in the current product.

  • Beats are available on Business and Enterprise plans
  • monitor-count limits depend on workspace entitlements
  • the nav can show Beats as locked when the feature is unavailable

That means a workspace might still see the idea of Beats in navigation, while the actual management surface remains gated until the plan includes synthetic monitoring.