Concepts and glossary
The nouns below mean one specific thing everywhere in the product and the docs.
Monitoring vocabulary
Section titled “Monitoring vocabulary”Monitor
Section titled “Monitor”The umbrella term for any scheduled health check. Site Qwality has six monitor families: HTTP (with the TCP port and ping check types), SSL/TLS, domain expiry, DNS record, cron heartbeat, and browser. A domain expiry check reads a domain’s registration from its registry; a DNS record monitor reads the domain’s records from its nameservers. The dashboard’s Monitors view lists all of them together.
A single execution of a monitor: one HTTP request, one TCP connection, one round of pings, one DNS lookup, one TLS handshake. Each check produces a result (success, failure, plus latency and any captured payload). An HTTP monitor with several check locations produces one check per location per tick. A browser check runs its script once in each location, and each run uses browser check minutes.
Run interval
Section titled “Run interval”How often a monitor’s checks fire. The minimum depends on your plan. Browser checks have their own fixed intervals (5m, 10m, 15m, 30m, 1h).
Check location
Section titled “Check location”A place Site Qwality runs checks from, on AWS, Google Cloud or Microsoft Azure, with a stable id such as aws-us-east-1 (the API field is check_regions). The default is aws-us-east-1 (Virginia, AWS), and for ping checks gcp-us-east4 (Virginia, Google Cloud), or gcp-us-west2 (Los Angeles) while Virginia is unhealthy. HTTP and TCP port checks can use any live location, ping checks the Google Cloud ones and browser checks any AWS location; SSL/TLS, domain expiry and DNS record checks run from aws-us-east-1. See check locations.
Min healthy regions
Section titled “Min healthy regions”For a monitor in several locations, how many must report healthy for a check to pass. With one location it is always 1 of 1.
Incident vocabulary
Section titled “Incident vocabulary”Incident
Section titled “Incident”An open record of “something is broken.” Incidents are opened by hand (dashboard or API), or automatically when a monitor linked to a service in auto mode starts failing. Each incident has:
- Status:
investigating→identified→monitoring→resolved. - Severity:
minor,major, orcritical. - Responder status:
triggered(no one’s looking),acknowledged(someone’s on it), orresolved. - Updates: a chronological log of status changes, posted internally and (optionally) to the public status page.
- Monitors and participants: the monitors it is about, and the people working it.
Incident update
Section titled “Incident update”A single timeline entry on an incident: a change of status with a written message (“We’ve identified a database failover; recovery in progress”). Posted via the dashboard or POST /incident/{id}/update.
Acknowledgment
Section titled “Acknowledgment”When a responder claims an incident, its responder_status flips from triggered to acknowledged. This stops further escalation but doesn’t resolve the incident.
Outage acknowledgment
Section titled “Outage acknowledgment”A person’s claim on a monitor outage, separate from an incident: it records who is on a down HTTP, heartbeat (cron) or browser monitor and, by default, stops that outage’s repeat alerts. The recovery alert is still sent. Acknowledge from the monitor page, the link in the down alert email, the API or an AI assistant. See Acknowledge a monitor outage.
Participant
Section titled “Participant”A person working an incident, with a role of lead, responder or comms. The first person to acknowledge becomes the lead. See Participants.
Merged incident
Section titled “Merged incident”A duplicate incident folded into another. It resolves with resolution_reason: "merged", and its monitors and participants move to the incident it was merged into. See Merge incidents.
On-call vocabulary
Section titled “On-call vocabulary”On-call schedule
Section titled “On-call schedule”A named rotation of users that produces “who’s on call right now” given a timestamp. Each schedule has one or more layers stacked in priority order, plus optional overrides.
A single rotation rule: which users participate, how often they hand off (daily, weekly, custom), at what time of day, optionally bounded by an effective_from / effective_until window. Layers with a higher layer_number are evaluated first and shadow lower ones during their effective window.
Override
Section titled “Override”A “user X is on call from time A to time B” entry that beats every layer, for covering someone’s shift.
Rotation type
Section titled “Rotation type”daily: handoff every day athandoff_time.weekly: handoff once a week athandoff_time, onhandoff_day(0=Sunday, 6=Saturday) when one is set. Both are interpreted in the schedule’s timezone.custom: handoff everyrotation_interval_daysdays.
Service vocabulary
Section titled “Service vocabulary”Service
Section titled “Service”A named part of your product, such as Checkout API, that ties monitors to incident handling. A service holds the escalation policy to page, an incident creation mode (manual or auto), a reopen window, an auto-resolve setting, a default severity for the incidents it opens, and optional broadcast targets. In auto mode it keeps one open incident that every failing monitor joins. Any monitor type can join a service. See Services.
Broadcast target
Section titled “Broadcast target”An email address, Slack channel or webhook that a service tells about every lifecycle event of its incidents (opened, acknowledged, updated, resolved, reopened, merged and moved), optionally filtered by severity and event. Separate from notification channels.
Escalation vocabulary
Section titled “Escalation vocabulary”Escalation policy
Section titled “Escalation policy”A named pipeline of “who to page if no one acknowledges.” Has an ordered list of levels, a repeat_count (how many more passes after the first, default 0) and an on_exhausted for when nobody acknowledges: email the account owners and admins (the default), stop, or run one other policy once. A level that can reach nobody is skipped at once.
Escalation level
Section titled “Escalation level”One step in the pipeline. Specifies a timeout_minutes (how long to wait for an ack before moving on) and a list of targets: target_user_ids (page these humans directly) and target_schedule_ids (page whoever’s on-call in these schedules right now).
Repeat count
Section titled “Repeat count”After running through every level, how many more passes to make before giving up, from 0 to 20. 0 means stop after one pass.
Notification vocabulary
Section titled “Notification vocabulary”Notification (channel)
Section titled “Notification (channel)”One delivery destination at the account level. Type-specific:
email→ an email addresssms→ a phone numberslack→ a channel inside a Slack integrationwebhook,discord,telegram,microsoft_teams,pagerduty,opsgenie,google_chat,mattermost,pushover,pushbullet→ reference an integration
A notification belongs to a notification group; it’s not attached to monitors directly.
Notification group
Section titled “Notification group”A bundle of notification channels that monitors attach to. Optionally has delay_send_after_minutes (wait this long before the first down alert) and resend_every_minutes (repeat the down alert until the monitor recovers or someone acknowledges the outage). Both apply to HTTP monitors and browser checks only. One group per account can be the default group (is_default), which new monitors get when they are created without groups; at signup that is the Default group.
Contact method
Section titled “Contact method”A user’s personal way to be reached: their email, their phone for SMS, or a Slack DM. Distinct from a notification channel: channels are to a destination; contact methods are to a person. On-call and escalation pages route to contact methods, not channels.
Notification rule
Section titled “Notification rule”A user’s personal preference: “for high-urgency incidents, SMS me at 0 min, Slack DM me at 5 min, email me at 15 min.” Stacks multiple rules with increasing delays per urgency level.
Urgency
Section titled “Urgency”Either high (wakes someone up) or low (informational). Derived from the incident’s severity: critical and major are high, minor is low. User notification rules are scoped to one urgency at a time.
Maintenance vocabulary
Section titled “Maintenance vocabulary”Maintenance window
Section titled “Maintenance window”A time range during which monitors with matching tags don’t page. Checks still run and results are recorded; failure notifications are held until the window ends, and a recovery inside the window clears the held page. Useful for planned deploys.
Two flavors:
- One-time: a single
starts_at/ends_atpair. - Recurring: a recurrence rule (e.g. “every Sunday 2am-4am UTC”).
Status page maintenance
Section titled “Status page maintenance”A separate object (not a maintenance window) that publishes “scheduled maintenance” cards on the public status page. Doesn’t silence anything; purely communicative. See Publish a status page maintenance.
Status page vocabulary
Section titled “Status page vocabulary”Status page
Section titled “Status page”A public, branded page at https://statuspage.siteqwality.com/<account-id>/<page-id> (or your custom domain) showing the current and historical state of components you choose to publish.
Status page component
Section titled “Status page component”One row on a status page, with a public-facing friendly_name: an HTTP check, browser check or heartbeat, whose status follows the monitor, or a manual component, whose status you set. HTTP and browser check components take an optional sla_target_percentage, and any component can carry a status override set by hand. See Group and order components.
Subscriber
Section titled “Subscriber”A visitor who confirmed an email address to be notified when the status page publishes an incident or maintenance. They can choose incidents, maintenance or both, and every component or only some. Email only.
Observability vocabulary
Section titled “Observability vocabulary”Metric
Section titled “Metric”A numeric time-series: gauge (current value), counter (monotonically increasing), or histogram (distribution of values bucketed by le). Tagged with key/value pairs for filtering and grouping.
A discrete event with a timestamp, level, message, and arbitrary structured metadata.
A distributed-tracing object: one trace = one logical request, made up of many spans. Each span has a service name, operation name, duration, and structured attributes. Site Qwality follows OpenTelemetry conventions.
RUM (Real User Monitoring)
Section titled “RUM (Real User Monitoring)”Telemetry collected from real browsers via the @siteqwality/rum SDK: page-load timings, web-vitals, errors, user actions, resource timing.
RUM application
Section titled “RUM application”One SDK installation, identified by an application_id and a client_token. Each app you instrument is a separate application, typically one per domain or one per major build.
Session replay
Section titled “Session replay”A recording of a user session, captured by the RUM SDK. Privacy-aware (mask_inputs, mask_text). Activated only when a Replay recording rule matches the session.
Account vocabulary
Section titled “Account vocabulary”Account
Section titled “Account”The top-level billing entity. One account = one subscription = one set of monitors, dashboards, and integrations.
A person with login credentials, scoped to one or more accounts. Roles are per-account.
API key
Section titled “API key”An account-scoped key, 96 hexadecimal characters, sent as a Bearer token. Create one under Settings → API keys. An Ingest only key can only send telemetry; a Full access key can also call the API, either everywhere or only within the scopes you tick.