StatIO tracks uptime, latency, and health signals for websites, APIs, and network endpoints. You can run checks from global workers or your own workers (BYOW) for private networks.

Use BYOW when the thing you’re monitoring is only reachable inside a LAN/VPN/VPC, or you need monitoring from a specific geography. BYOW uses outbound HTTPS only; no inbound ports required.

Yes. You can publish read-only dashboards for customers or stakeholders, or keep them private within your account/projects.

You define alert conditions (availability, latency/metric thresholds) and StatIO evaluates them as results arrive. Use this for outage detection, SLA monitoring, and performance regression alerts.

A worker is an execution agent that runs monitors (checks) and reports results back to StatIO. Workers can be global (hosted by StatIO) or bring-your-own (BYOW) for private environments.

No. Workers initiate outbound HTTPS to the StatIO API. You do not need to open inbound ports to receive results.

A monitor can be assigned to one or more workers. Assignments control where checks run (global regions, project BYOW instances, or both). If a monitor has no enabled assignments, it won’t produce results.

Yes (when available). Some views allow filtering a tile’s query to a specific assigned worker, so you can compare regions, isolate a problematic execution environment, or validate a private-network path.

BYOW is designed for constrained networks: the worker runs inside your environment and sends results outbound over HTTPS. This avoids exposing internal endpoints to the public internet.

A monitor is a configured check (HTTP/TCP/ICMP/DNS/SSL or push) with an interval and timeout. Workers execute monitors and produce result events and metrics.

Common types include HTTP, TCP, ICMP (ping), DNS, SSL checks, and push monitors. Each kind has its own configuration (for example: HTTP method/headers/body, DNS record type, TCP port).

A push monitor is for services that can’t be pulled reliably (batch jobs, cron tasks, or systems behind strict firewalls). Your service posts results to a StatIO endpoint, and StatIO treats those posts as check results.

Yes. Push monitors can use an optional access key. If set, it is stored hashed and cannot be displayed again. Blank is meaningful: leaving it blank means no key is required.

Interval controls how often a worker runs a check; timeout is the maximum time a worker will wait for completion (for example, an HTTP response). Plans may enforce a minimum interval.

A dashboard is a collection of tiles that visualize monitor metrics over time. Dashboards can be private to your account/project or published read-only for sharing.

A tile is a single visualization panel on a dashboard (time series, stat, bar/count-by-value, map, or summary). Tiles query monitor results and render an aggregated view.

Tiles are configured by scope (monitor + optional worker), a metric path, a display type, an aggregation operator (e.g., avg/last), and time controls (range + bucket). Optional transforms (“pipe”) can derive new values from raw metrics.

A Summary tile is a simplified tile scoped by monitor and (optionally) worker only. It does not use metric queries, transforms, thresholds, or alarms. It’s intended for at-a-glance monitor status/overview.

Range is the time window displayed (e.g., last 1 hour, 24 hours). Bucket is the aggregation interval used to group points (e.g., 10s, 1m, 5m). Plans may enforce a maximum range.

For string metrics, “count by value” groups and counts occurrences of each distinct string value. It’s useful for categorical telemetry (status strings, error codes, user agents, etc.). Stat tiles can reduce count-by-value into a single number/value (e.g., top value or % of a value).

Pipes apply simple transforms to metric values before aggregation/thresholding. Examples: trim/lower/upper for strings, len (string → number), regex test (string → boolean), numeric rounding, or explicit casts.

Thresholds define green/yellow/red boundaries for a tile’s effective output (number/boolean/string depending on the tile). Thresholds are used to produce status chips and drive alarm triggers.

Alarms trigger when a tile’s evaluated status enters a configured trigger state (typically yellow or red). If a tile has no thresholds, there’s no status to alarm on.

Yes. When creating a new tile, alarms can be drafted in the UI. After the tile is created, drafted alarms are created against the new tile automatically.

Commonly email-based notifications are supported. Alarm rules define who to notify and what conditions trigger a notification (severity, triggers, and other gating rules if enabled).

For a monitor up/down alarm, create an alarm based on the monitor’s “ok” metric (or equivalent boolean status), and set thresholds/triggering accordingly. Summary tiles do not support alarms directly.