Concepts Checks

Checks

A Check is a scheduled probe that tests whether a resource is healthy. Checks belong to a Service and run automatically on a schedule (every minute by default). Their results drive the Service's status on your status page.

How checks work

Every minute, Piro runs each active check and records a result: UP, DEGRADED, DOWN, or FAILURE. The worst result across all checks in a Service becomes the Service's public status.

You can tune how sensitive each check is with two thresholds:

• Failure threshold — how many consecutive failures before the check is considered down (avoids flapping)
• Recovery threshold — how many consecutive successes before it's considered recovered

A real-world example

Say you're monitoring a SaaS app called Acme. You might set it up like this:

Service: Acme Web App
├── HTTP check    → https://app.acme.com/health       (is the app responding?)
├── SSL check     → app.acme.com                      (is the cert valid?)
└── DNS check     → app.acme.com (A record)           (does DNS resolve correctly?)

Service: Acme API
├── HTTP check    → https://api.acme.com/status       (API health endpoint)
└── TCP check     → api.acme.com:5432                 (database port reachable?)

Service: Acme Background Jobs
└── GCP Cloud Run Job → acme-data-sync (runs nightly)

Multi-region checks

Enable multi-region on a check to run it from all connected Workers simultaneously. Piro takes the worst result across all regions — useful for catching region-specific outages.

Criticality

Each check has a criticality that controls how its failure affects the Service status:

Criticality	Effect on Service
Critical	Service goes DOWN
High / Medium / Low	Service goes DEGRADED

Use Critical for checks that confirm total unavailability (e.g. the main health endpoint). Use High or lower for checks that indicate partial problems (e.g. a secondary feature or latency warning).

Supported check types

Type	What it monitors
HTTP	HTTP/HTTPS endpoints — status codes, response body, latency
TCP	Open TCP ports — database, SMTP, Redis, any TCP service
Ping	ICMP ping — raw reachability and round-trip latency
DNS	DNS resolution — A, AAAA, CNAME records; multi-nameserver
SSL	TLS certificates — validity, expiry warnings
GCP Cloud Run Job	Google Cloud Run job executions — success, failure, staleness

Heartbeat and GRPC are planned but not yet implemented.

Related

• Services — Services group Checks and display their rolled-up status
• Triggers — send alerts when a check changes status