Skip to content

Documentation

Pingio documentation

How monitors, incidents, notification channels, and public status pages fit together.

Getting started

Create an account, add your first monitor, and connect a notification channel. Pingio starts checking immediately and shows the first result within one interval.

Every monitor needs a target, a check type, and an interval. Everything else has a sensible default that you can refine later.

  • Add a monitor from the dashboard or through the API.
  • Connect at least one channel so alerts have somewhere to go.
  • Open the monitor detail page to see the raw check history.

Monitor types

Pingio supports HTTP(S), keyword, TCP port, ping, SSL certificate, and server agent checks. Each type has its own assertions and timeout policy.

  • HTTP(S): status code, response time, redirects, and request headers.
  • Keyword: assert that a phrase is present or absent in the response body.
  • TCP and ping: reachability of a host and port from several regions.
  • SSL: certificate expiry, chain validity, and hostname match.
  • Server agent: CPU, memory, and disk metrics reported by an installed agent.

Scheduling and verification

Monitors are queued by interval and dispatched to workers. When a check fails, Pingio re-runs it from a different region before opening an incident, so one unhealthy route never pages your team on its own.

Once an incident is open, Pingio keeps checking on the normal schedule and closes the incident automatically after the configured number of successful checks.

Incidents and notifications

Repeated failures are grouped into a single incident with a timeline. Notifications are sent when the incident opens, when reminders are due, and when it is resolved.

Reminder intervals and the maximum number of reminders are configured per team so long outages stay visible without flooding your channels.

  • Email, Telegram, Slack, SMS, and generic webhooks.
  • Per-monitor channel routing and quiet hours.
  • Deduplication so one outage never produces duplicate alerts.

Public status pages

Every team can publish one or more status pages that show current monitor state, incident history, and scheduled maintenance. Status pages are localized and indexed by search engines.

API access

The REST API mirrors the dashboard. Use it to create monitors from infrastructure code, pull check history into your own dashboards, or trigger maintenance windows during a deploy.

{
  "name": "Primary website",
  "type": "http",
  "target": "https://example.com",
  "intervalSeconds": 60,
  "regions": ["eu-central", "us-east"],
  "assertions": {
    "status": 200,
    "contains": "Welcome"
  }
}