Core concepts
The building blocks of SutramX — monitors, checks, regions, confirmation, monitor states, incidents, alerts, status pages, maintenance, workspaces and plans.
This page explains the terms used across SutramX and how they fit together. Each section is short and links to the page with the full details.
How the pieces fit together#
- A monitor describes something to check: a URL, host, port, DNS name, MCP server or scheduled job.
- On every interval, probe regions run a check against it.
- When checks fail, SutramX confirms the failure (a retry, a streak, and agreement between regions) before it opens an incident.
- The incident sends alerts through your channels. If nobody acknowledges it, it can escalate.
- Status pages show the monitor's state to your users. Maintenance windows keep planned work from paging anyone.
- All of this lives in a workspace that your team shares, with limits set by your plan.
Monitors#
A monitor is one thing SutramX watches, plus the rules for deciding whether it's healthy. Each monitor has a name, a type, a target, a check interval, the locations it's checked from, and optional rules such as expected status codes or keywords.
| Type in the dashboard | What it checks |
|---|---|
| Website (is the page up?) | A URL answers with an expected status code, within time limits, optionally containing (or not containing) keywords |
| API endpoint | An API endpoint, with methods, headers, a request body, authentication and response assertions |
| Multi-step API check | A sequence of API requests, where later steps can use values from earlier responses |
| Server ping (ICMP) | A host answers ping |
| Port (database, mail…) | A TCP connection to a host and port succeeds |
| UDP port (DNS, game servers…) | A UDP service answers, optionally with an expected response |
| DNS records | DNS records for a name, alerting when they change or stop matching values you expect |
| Scheduled job (cron) heartbeat | Your job calls a SutramX URL on schedule; a missed or failed call is a failure |
| MCP server | A remote MCP server completes the initialize handshake and lists its tools |
SSL certificate and domain expiry reminders aren't a separate type. You turn them on for any website or API monitor.
You can organise monitors into groups (shown as tabs on the Monitors page) and label them with tags for filtering.
Learn more: Monitors overview, Monitor settings & groups, SSL & domain expiry.
Checks and intervals#
A check is one attempt to reach a monitor's target from one location. Its result is up, degraded or down, along with details such as response time, status code and error message. The check interval is how often a monitor is checked. The fastest interval you can pick depends on your plan.
Heartbeat monitors work the other way round. Instead of SutramX contacting your server, your job calls a unique URL each time it runs. The monitor fails if the call doesn't arrive within the expected schedule plus a grace period. Learn more: Heartbeat & cron.
Probe regions#
A probe region (also called a location) is a place SutramX runs checks from. Your plan decides how many regions each monitor can use, and you pick which ones in Check from or Locations. Checking from several regions shows you regional problems and lets SutramX confirm outages before alerting.
| Region | Code | Country | Continent |
|---|---|---|---|
| FRA1 (Frankfurt, Germany) | fra1 | Germany | Europe |
| AZ (Arizona, USA) | usa-az-probe | — | — |
| IN (Mumbai) | in-mumbai | India | Asia |
Learn more: Regions & confirmation.
Confirmation and quorum#
One failed check doesn't wake anyone up. Before an incident opens, SutramX confirms the failure in three ways:
- Retry. When a check fails because of a network problem, a timeout or a server error, the same region checks again a few seconds later.
- Failure threshold. A region only counts as down after this many failed checks in a row. You can set it between 1 and 10; the default is 1.
- Quorum. On plans with more than one region, a minimum number of regions must report the monitor down at the same time. The quorum depends on your plan and is never more than the number of regions the monitor uses.
New monitors checked every minute or faster also have a Confirmation period of 30 to 60 seconds: a failure must last that long in a region before it counts. You can change it under Detection in the monitor's advanced options.
Recovery works the same way in reverse. The Recovery threshold (1 to 10, default 1) sets how many passing checks in a row are needed, and enough regions must agree that the monitor is back up. New monitors checked every minute or faster also have a 60-second Recovery period.
Learn more: Regions & confirmation.
Monitor states#
Every monitor shows one of these states in the dashboard:
| State | Meaning |
|---|---|
| Up | The latest check passed |
| Down | A confirmed incident is open for the monitor |
| Degraded | The monitor answered but slower than your Degraded above (ms) threshold, or a check failed and the failure isn't confirmed yet. Degraded never opens an incident on its own |
| Blocked | The site's bot protection or rate limiting refused the latest check. Not counted as downtime |
| Inconclusive | SutramX's checker couldn't reach a verdict, a problem on our side. Not counted as downtime |
| Pending | The monitor has no check results yet, for example just after you create it |
| Paused | You paused the monitor, or your plan paused it (for example after a downgrade). Paused monitors aren't checked |
| Maintenance | A maintenance window currently covers the monitor |
Incidents#
An incident is a confirmed outage of one monitor. It opens when confirmation succeeds and resolves automatically when the monitor recovers. From the incident page you can:
- Acknowledge it, which tells your team someone is on it and stops further escalation steps.
- Snooze alerts for a while.
- Resolve it manually with an optional note.
- Add notes. A note marked public appears on your status pages.
- Write a postmortem after it's resolved.
On plans that include them, AI can summarise the incident, draft status page updates and draft a postmortem.
Learn more: Incidents, AI incident assist.
Alerts and channels#
An alert is a notification about a monitor going down or recovering. The same channels can also receive SSL and domain expiry warnings and maintenance notices.
Email alerts go to the workspace owner's verified email and to any recipients you add per monitor or per group. Channels are other destinations you connect on Alerts → Channels & API:
- Chat apps: Slack, Discord, Microsoft Teams, Google Chat, Mattermost and Telegram.
- Automation: webhooks, Zapier and GitHub issues.
- Incident tools: PagerDuty and Opsgenie.
- Phone: SMS, WhatsApp and voice calls.
- Browser push: notifications in your browser.
Some channels are only on paid plans. SMS, WhatsApp and voice use alert credits.
An escalation policy sends further notifications, step by step, until someone acknowledges. An on-call schedule decides who is on call at any moment. Quiet hours and deployment windows suppress notifications during set periods.
Learn more: How alerting works, Escalation & on-call.
Status pages#
A status page is a public (or protected) web page for your users. It shows the current state of the monitors you choose, 90 days of uptime, incidents and scheduled maintenance. Visitors can subscribe by email or follow an Atom/RSS feed. Depending on your plan, you can put it on your own domain, protect it with a password or SSO, offer extra languages and remove SutramX branding.
Learn more: Status pages overview.
Maintenance windows#
A maintenance window is a scheduled period of planned work. It can happen once or repeat daily or weekly, and it covers all monitors, specific monitors or monitor groups.
During a window, down alerts are held back and the affected monitors show Maintenance. The window doesn't count against uptime. If a monitor is still down when the window ends, the alert is sent then.
Learn more: Maintenance windows.
Workspaces#
A workspace holds monitors, incidents, status pages, alert settings, integrations and the subscription. Every account gets its own workspace when it signs up. When someone invites you to their workspace, you can belong to several and switch between them with Active workspace in the sidebar. The picker only appears when you have more than one.
Learn more: Workspaces.
Team and roles#
People in a workspace have one of three roles:
- Owner. There's one per workspace. The owner manages members, billing and plans, API keys, integrations and alerting settings, status page custom domains, data export and deleting the workspace.
- Member. Members work with monitors, groups, incidents and status pages day to day.
- Viewer. Viewers can see everything a member sees but can't change anything.
Team seats are unlimited on every plan. Being a team member doesn't by itself send you alerts; you must be added as an alert recipient, to a group or to an escalation policy.
Learn more: Team members & roles.
Plans#
SutramX has four plans: Free, Starter, Growth and Pro. Plans differ in the number of monitors, the fastest check interval, how many regions each monitor uses and how many must agree, status pages, API keys, alert credits, and which features are included. Free has no time limit and needs no card.
Learn more: Plans & limits.
Related
- Quickstart
- Dashboard tour
- Glossary
- Monitors overview
- How alerting works
- Features: Multi-Region Probes and Why This Alert
- Guides: What Is Uptime? and Reducing False Alerts
- More from SutramX: How We Check
Last updated . Something unclear or missing on this page? Tell us at support@sutramx.com.