Skip to main content

Beats

Beats are StatiBeat's monitoring workspace. They help page admins check customer-facing paths, capture evidence, and turn trusted signals into alerts, drafts, or public status updates.

tip

Beats work best when they are tied to the same services and communication model your customers already see on the status page.

Watch the Beats walkthrough​

This four-minute walkthrough shows a simple Beat from setup through failure, recovery, screenshot evidence, and automated public status-page messaging.

Text alternative

The walkthrough creates an HTTP Beat for a public health endpoint, sets the successful response to HTTP 200, and configures one failed check to move the Beat to critical. It then sends a recovery result, reviews a browser-journey screenshot, and shows how Beat results can create and resolve a customer-facing incident. The demo keeps actions in a simple, understandable flow so an operator can review the evidence before expanding automation.

When to use Beats​

Use Beats when you want StatiBeat to help answer:

  • is this customer-facing path healthy right now?
  • should an operator review a warning before it becomes public?
  • should repeated failures create a draft or incident automatically?
  • what evidence should the team see before communicating?

Good early Beats are simple, important checks:

  • a homepage or status page HTTP check
  • a core API health endpoint
  • a certificate check for a public hostname
  • an internal readiness endpoint through Private Beat

Start with one or two high-value checks. Tune thresholds and review behavior before expanding to a large monitor set.

Create a Beat​

The create flow opens in Wizard mode for common setups.

  1. Choose the monitor type.
  2. Tell StatiBeat what to check.
  3. Choose alert behavior.
  4. Attach the Beat to the affected service or component.
  5. Review the summary before creating it.

Use Advanced mode when you need the full configuration surface, such as detailed thresholds, screenshots, network capture, request headers, or custom message templates.

Existing Beats open in the advanced editor so their full configuration stays visible and editable.

Beat types​

StatiBeat supports several Beat types:

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

Choose the simplest Beat that proves the thing users care about. A basic HTTP or API check is usually a better first step than a complex journey.

For a short guide to choosing between Beat types, see Beat Types.

Beat Groups​

Beat Groups let several checks behave like one customer-facing operational surface.

For example, a website health group might include:

  • HTTP availability
  • latency
  • certificate health
  • ping or packet loss

The individual Beats still collect evidence. The Beat Group owns the shared customer-facing behavior, such as incident creation, messaging, cooldowns, and review settings.

Attach Beats to your service model​

Attach Beats to hierarchy items when a failing check should affect the public status page or a specific service detail page.

Use free-text affected scope when the Beat covers something that is important but not modeled directly in the hierarchy, such as a vendor API or queue worker.

Public-facing actions need clear affected scope. A Beat can stay internal-only until you are confident its failures map cleanly to customer impact.

Private Beat​

Use Private Beat for targets StatiBeat cannot reach from its shared runtime, such as private networks, internal services, or localhost health checks.

The usual setup is:

  1. Create a Private Beat.
  2. Choose Internal HTTP health check or Basic heartbeat only.
  3. Configure the target URL when using HTTP mode.
  4. Generate an installer command or download the installer bundle.
  5. Run the installer on a host that can reach the private target and can call StatiBeat over outbound HTTPS.
  6. Confirm the Beat starts reporting.

Use heartbeat-only mode when you only need to know whether the host or agent is alive. Use HTTP mode when the agent should also verify an internal endpoint.

External Beat Triggers​

Use External Event Beats when another system already owns the detection signal.

Examples include:

  • cloud monitoring alerts
  • Datadog or Elastic alerts
  • deploy pipeline events
  • internal queue or canary jobs

In StatiBeat, create an ingest endpoint, inspect incoming events, build a rule, preview it against historical events, and attach the rule to a Beat or Beat Group. Keep customer-facing posting in review mode until the preview is trustworthy.

For the detailed event-rule workflow, see External Beat Triggers.

AI-assisted Beat workflows​

When AI is configured for the page, Beats can offer:

  • Create with AI for drafting a Beat from a natural-language request
  • AI Info for summarizing evidence and likely next steps on failing Beats

AI-created Beat changes are not applied directly. StatiBeat shows a normalized preview and waits for confirmation before writing.

Public metrics​

If a Beat is mapped to a public service and public metrics are enabled, visitors can see a simple service-level metrics view.

Public metrics are designed for readability, not operator forensics. Keep detailed evidence, raw checks, and investigation notes in the admin workspace.

Good rollout pattern​

  1. Create one or two important Beats.
  2. Attach them to the right hierarchy items.
  3. Keep public actions in review mode at first.
  4. Run manual tests and inspect the generated evidence.
  5. Tune thresholds and messages.
  6. Only then enable automated public actions for well-understood checks.