Core Concepts

This page explains the fundamental concepts you'll encounter when using Statly.

Organizations

An organization is your top-level container in Statly. Each organization has:

A unique slug (e.g., acme) for the status page URL
Team members with different roles
Monitors, incidents, and settings

Roles

Role	Permissions
Admin	Full access: manage team, billing, settings, and all features
Member	View and manage monitors, incidents; cannot manage team or billing

Monitors

A monitor is a scheduled check that verifies your service is working. Statly supports:

HTTP Monitors

Check web endpoints for expected responses:

URL: The endpoint to check
Method: GET, POST, PUT, DELETE, etc.
Expected Status: 200, 201, 204, etc.
Timeout: How long to wait (1-120 seconds)
Headers: Custom headers to send
Body: Request body for POST/PUT

TCP Monitors

Check that a port is accepting connections:

Host: Server hostname or IP
Port: Port number to check

DNS Monitors

Verify DNS records are resolving correctly:

Hostname: Domain to query
Record Type: A, AAAA, CNAME, MX, TXT
Expected Value: What the record should resolve to

Heartbeats

A heartbeat is a single check result. Each heartbeat records:

Timestamp: When the check ran
Status: up, down, or degraded
Response Time: How long the check took (ms)
Region: Which probe region ran the check
Error: Error message if the check failed

Uptime

Uptime is calculated as the percentage of successful heartbeats:

Uptime = (Successful Heartbeats / Total Heartbeats) × 100

Statly calculates uptime over different windows:

24 hours
7 days
30 days
90 days

Incidents

An incident communicates a service disruption to your users. Incidents have:

Status

Status	Description
`investigating`	Team is looking into the issue
`identified`	Root cause has been found
`monitoring`	Fix deployed, watching for stability
`resolved`	Issue fully resolved

Severity

Severity	Description
`major`	Complete service outage
`minor`	Partial degradation or feature unavailable
`maintenance`	Planned maintenance window

Updates

Each incident can have multiple updates as the situation evolves:

12:00 PM - Investigating: We're looking into reports of slow API responses.
12:15 PM - Identified: Database connection pool exhausted.
12:30 PM - Monitoring: Fix deployed, monitoring stability.
1:00 PM - Resolved: All systems operational.

Status Pages

A status page is your public-facing page showing service health:

Overall Status: Aggregated from all monitors
Components: Grouped monitors (e.g., "API", "Website", "Database")
Incidents: Current and recent issues
Uptime Graph: Visual history of service availability

Status Values

Status	Display
`operational`	All systems operational (green)
`degraded`	Performance issues (yellow)
`partial_outage`	Some components down (orange)
`major_outage`	Major service disruption (red)

Subscribers

Subscribers are users who sign up to receive notifications about your status:

Email notifications for incidents and maintenance
Component-level subscriptions (only get notified about relevant services)
Email verification required before receiving notifications

API Keys

API keys provide programmatic access to the Statly API:

Format: sk_live_<64-character-hex>
Scopes: monitors:read, monitors:write, incidents:read, incidents:write, *
Keys are hashed before storage and cannot be retrieved after creation

SDK Events

When using the Observe SDKs, you'll work with:

Events

An event is a captured error or message:

Exception: Error type, message, and stack trace
Context: User, tags, and extra data
Breadcrumbs: Trail of actions leading to the error

DSN (Data Source Name)

The DSN configures where to send events:

https://sk_live_<api-key>@statly.live/<org-slug>

The SDK parses this to extract the API key and organization.

Quick Start Plans & Pricing