Glossary
Quick definitions of the terms you’ll meet throughout Aloft, in alphabetical order.
API key
Section titled “API key”A Bearer token (prefixed ur_) that authenticates requests to the /api/v1
REST API. Keys are scoped to one organization, shown in full only once at
creation, and managed by admins. See
API and integrations.
Channel
Section titled “Channel”A reusable notification destination — email, Slack, Discord, a signed webhook, and more. You define a channel once and attach it to any monitors that should alert through it. See Channels.
A single execution of a monitor’s probe — one request, ping, or certificate read — recorded with its result and response time. Checks run on the monitor’s interval.
Confirmation re-check
Section titled “Confirmation re-check”The requirement that a monitor fail a configured number of consecutive checks before Aloft opens an incident. This prevents a single transient blip from paging anyone.
Degraded
Section titled “Degraded”A monitor state where the check succeeded but the response was slower than the configured response-time threshold. The endpoint is reachable but sluggish; degraded still counts as “up” for uptime calculations.
Heartbeat
Section titled “Heartbeat”A monitor type that waits for your job to check in (by posting to an ingest URL) instead of Aloft probing outward. If the expected check-in doesn’t arrive within the interval plus grace period, the monitor goes down. See Heartbeat monitors.
Incident
Section titled “Incident”A period during which a monitor is down. Aloft opens an incident when enough consecutive checks fail and resolves it when checks pass again, recording the total downtime. See Incidents.
Maintenance window
Section titled “Maintenance window”A planned time range during which Aloft suppresses incidents and alerts for the covered monitors, so scheduled work doesn’t trigger false alarms. See Maintenance windows.
Monitor
Section titled “Monitor”A single thing you want Aloft to watch — a URL, TCP port, host, TLS certificate, domain registration, or background job. Each monitor has a type, schedule, and its own status. See Monitors overview.
Organization
Section titled “Organization”The container that owns everything in Aloft — monitors, channels, status pages, and API keys. You belong to at least one organization and can be a member of several. See Teams & roles.
Region
Section titled “Region”A location from which checks can be executed, letting Aloft probe a target from more than one vantage point so a single network path doesn’t skew results.
A member’s permission level within an organization (such as admin). Roles gate sensitive actions — for example, managing API keys requires admin. See Teams & roles.
Rollup
Section titled “Rollup”A periodic aggregation of raw check rows into summarized buckets, so uptime and response-time history stay fast to query and storage stays bounded over time.
SSRF guard
Section titled “SSRF guard”A safety filter that blocks probes and webhook deliveries from reaching private,
loopback, or cloud-metadata addresses by default. An admin can relax it with
ALLOW_INSECURE_TARGETS=1 to monitor internal hosts.
Status page
Section titled “Status page”A public, shareable page that displays the live status and uptime history of selected monitors. Anyone with the link can view it. See the Status pages section in the top navigation.