Monitor
Uptime, SSL certificate and domain expiry monitoring from Norcube's servers, with confirmed incidents, alerts by email, webhook, Slack, Discord or SMS, and public status pages.
Norcube Monitor checks your websites, APIs, TLS certificates and domain registrations on a schedule from Norcube's servers. A problem that consecutive checks confirm opens an incident, and the incident alerts the channels you chose: email, a signed webhook, Slack, Discord or SMS. When the checks pass again, the incident resolves and a recovery alert closes the loop. A public status page shows chosen monitors to your customers, at a Norcube address or on your own domain.
How it fits together
| Concept | What it is | Scope |
|---|---|---|
| Monitor | One thing to watch: an HTTP URL, a TLS certificate at host:port, or a registered domain. Has a name, an interval and the settings of its kind. | Organization |
| Check | One run of the monitor, scheduled or on demand. Records a severity (ok, warning, critical or inconclusive), a condition code, timings and, where it applies, a certificate or a registration. | Monitor |
| Aspect | What a result is about: availability, certificate or domain. Each kind judges one primary aspect. An HTTP monitor can also watch its certificate and its domain as extra aspects. | Monitor |
| Incident | A confirmed problem of one aspect. At most one open incident per monitor and aspect. Carries a severity, a timeline and every alert sent for it. It is internal to your organization. | Monitor, aspect |
| Alert channel | Where alerts go: an email address or the organization's members, a webhook endpoint, a Slack or Discord incoming webhook, or a mobile number. Can be marked as a default channel. | Organization |
| Alert route | One channel plus the events it gets (down, warning, expiring, expired, recovered), set per monitor. Without its own routes a monitor alerts the organization's default channels. | Monitor |
| Status page | A public page of components, under names you pick, that follows your monitors and carries the incidents you post. | Organization |
Monitors say what to check and how often. Incidents say what is wrong right now. Channels and routes say who hears about it. Status pages say what your customers see.
What you can do
Watch a website or API
Method, headers (plain or secret), body, accepted statuses, timeout, slow threshold, redirects, TLS verification and a keyword that must be present or absent.
Catch expiring certificates
A TLS handshake to any host and port. Chain, hostname and validity are checked on every run; expiry alerts at the thresholds you set.
Never lose a domain
The registration of a domain, looked up through DomainRadar. Alerts before it expires, and if it ever expires or is not registered.
Get alerted
Email, webhook, Slack, Discord and SMS channels. Default channels for every monitor, or routes per monitor and event.
Receive signed webhooks
JSON alerts signed per Standard Webhooks, with a payload you can verify and act on.
Track incidents
Open and resolved incidents with a timeline, the alerts sent, acknowledgement, and the time to resolve.
Gate deploys from CI
Fail a pipeline while a critical incident is open, or run a monitor's check right after a deploy.
Script it
The same API the dashboard uses, with scoped CI tokens and RFC 9457 errors.
How a check runs
- On a schedule. Every monitor has an interval between 30 seconds and 1 day. Your organization has a limit on the shortest interval, 60 seconds by default. Domain monitors run at most hourly, because registries change slowly and throttle lookups. You can also run a check on demand with Check now.
- From one region. Checks run from
eu-central-1(Frankfurt). Every result says which region checked it, and every monitor lists its regions. All checks leave from the source IP18.185.27.174. Add it to your allowlist if your target is behind one. - Judged by its kind. A check ends with a severity and a condition
code:
ok,warning(a slow response, a certificate or domain expiring within a threshold) orcritical(down, expired, invalid, not registered). A check that could not reach a verdict (a failed registry lookup, an internal error) isinconclusive: it is stored and shown, but it moves neither the monitor's status nor an incident. - Confirmed before it alerts. An availability problem has to repeat
for a number of checks in a row before an incident opens (2 by
default, up to 10). Expiry conditions open an incident at once: there
is nothing to confirm. An incident resolves after the number of ok
checks you set (1 by default) and sends one
recoveredalert. - Reminded until someone acts. While a critical incident stays open and nobody has acknowledged it, its alert repeats every 60 minutes by default (15 minutes to 24 hours, or off).
Paused monitors are not checked. Scheduled and on-demand checks count towards your usage alike.
Status pages
A status page shows your customers how your services are doing. Each row is a component with a public name you pick, and its status follows your monitors' incidents. Your incidents stay internal: what the public reads about them is what you post.
Create a status page
Choose an address and the settings, then set what the page shows.
Layout
Components, groups, public names and the aspects that count.
How component status is decided
Confirmed incidents, no data, and what a posted incident changes.
Post incidents
Tell the public what is happening, separately from your monitors' incidents.
Publish and preview
Go public, share a 15-minute preview, change the address.
Custom domains
Serve a page from a subdomain you control, such as status.acme.com.
Logo
Show your logo in place of the page's name, with an optional dark mode image.
Languages
Eight languages, chosen for each visitor. Your own text stays as written.
Public data
page.json and the Atom feed.
Limits, scope and permissions
The limit, the monitor.statuspages scope and IAM actions.
CLI
Manage pages and post incidents with nrc monitor status-pages.
Pricing
Norcube Monitor is free to start. Usage is metered from the start: HTTP, SSL and domain checks, and email, webhook (including Slack and Discord) and SMS notifications, each counted per organization and hour, and active custom domains. Prices will be published before anyone is charged.
Every organization starts with the default limits: 10 monitors, a
shortest interval of 60 seconds, 10 SMS a day, one status
page and a safety cap of 10 custom domains. At the monitor cap, creating another monitor is refused with
403 LIMIT_REACHED (reason MONITOR_LIMIT). An organization blocked
for unpaid invoices stops being checked and gets 402 ORG_BLOCKED on
on-demand actions; see Billing.
Reference
- Getting started: the quickstart
- CLI, and every command and flag in the CLI reference
- API