Monitors
The kinds of monitors, intervals and statuses, the monitor list with filters and bulk actions, and the detail page with uptime, response times, history and CSV export.
A monitor is one thing Norcube Monitor checks on a schedule. Every monitor has a name, an optional description, an interval and the settings of its kind.
Kinds
| Kind | Target | What a check does | Primary aspect | Tracks uptime |
|---|---|---|---|---|
| HTTP / website | A URL | Sends a request and judges the status code, the response time and, optionally, a keyword in the body. | Availability | Yes |
| Keyword | A URL | An HTTP monitor with the keyword check switched on. Shown as Keyword in lists; the API type is http. | Availability | Yes |
| SSL certificate | host:port | A TLS handshake. Checks the chain, the hostname and the validity, and warns before the certificate expires. | Certificate | No |
| Domain expiry | A registered domain | Looks the registration up through DomainRadar and warns before it expires. | Domain | No |
An HTTP monitor can additionally watch the expiry of its certificate and of its domain. Watches are extra aspects with incidents of their own; they never change whether the site counts as up. See Expiry watches.
Intervals
The Check every picker offers 30 seconds, 1, 2, 5, 10, 15 and 30 minutes, 1, 6 and 12 hours and 1 day. The API accepts any value from 30 to 86,400 seconds, with two floors:
- Your organization has a limit on the shortest interval, 60 seconds by default. The form says so under the picker.
- Domain monitors run at most hourly. Registries change slowly and throttle lookups.
New HTTP and SSL monitors start at 1 minute in the dashboard, new domain monitors at 12 hours.
Statuses
A monitor's status is the severity of its last conclusive check:
| Status | Meaning | In the kind's words |
|---|---|---|
| Pending | Created, no conclusive check yet. | Pending |
| OK | The last check passed. | Up, Valid, Registered |
| Warning | It works, but not well. | Slow, Expiring |
| Critical | The target doesn't work, or has expired. | Down, Expired, Invalid, Unreachable, Not registered |
| Paused | Not checked until resumed. | Paused |
An inconclusive check (a failed registry lookup, an internal error) changes nothing. The monitor page then says "Couldn't verify since ..." and keeps showing the last known status.
The overall status is the worst of the monitor's own status and its watches' statuses. The list's counts, status filter and default sort read the overall status, so an HTTP monitor that is up with an expiring certificate shows as a warning.
The monitor list
Monitors in the sidebar opens the list. Above it, a summary band shows the organization at a glance: a headline, a bar with each status' share and chips that filter the list, the last 24 hours across all monitors (uptime of the HTTP monitors weighted by checks, incidents opened, estimated time down), and your monitors against your limit.
The toolbar has a search box (name or target), Status and Type filters, a sort (Problems first, Name, Uptime, Last checked, Newest) and a density toggle between rows and a compact table. Filters and sort live in the URL, so a link shares the view. Each row shows the status, the name, the target, the kind, the primary figure (uptime over the last 24 hours and the p95 response time for HTTP, days until expiry for the others) and a strip of the last 60 checks.
Row menu
The ⋯ menu on a row (and the vertical dots on the detail page) offers: Edit monitor, Alert settings, Check now, Pause monitor or Resume monitor, Clone monitor, Copy URL, View incidents and Delete monitor. Items you may not use are left out.
- Check now runs the check immediately. It is stored and billed like a scheduled check and rate limited to 200 per user and 600 per organization an hour. The dashboard hides it while the monitor is paused; the API and CLI run paused monitors too.
- Pause stops scheduled checks and closes the monitor's open incident quietly (no alert). A status page component that follows the monitor shows "No data" while it is paused. Resume checks right away unless the last check is less than an interval old. Pausing and resuming are idempotent.
- Clone monitor opens the create form filled from the monitor. Secret header values are never copied; the form tells you how many to fill in again.
- Delete monitor removes the monitor with its whole check history and incidents, and its components from every status page. It cannot be undone.
Bulk actions
Tick the boxes on the rows (or Select all loaded monitors in the header) and the toolbar turns into Pause, Resume and Delete for the selection. A new filter or sort clears the selection. A bulk request handles up to 100 monitors, one by one: a monitor that cannot be changed (not found, no permission, managed by another service) is reported above the table and the others still go through.
Linked monitors
A monitor can belong to a resource of another Norcube service. Today
DomainRadar creates a domain monitor for a saved domain with expiry
alerts on. Such a monitor shows Managed by DomainRadar: you can
rename it and change its interval and thresholds, but its domain is set
in DomainRadar and it is deleted by turning the expiry alerts off there.
Deleting it in Norcube Monitor is refused (409 MANAGED_RESOURCE).
The monitor page
A monitor's page has four tabs: Overview, Incidents, Settings and Alerts. The header shows the status, the name, the target, a Test notification button, Pause or Resume and Edit. It refreshes every 30 seconds.
Overview
The hero at the top shows the signal that matters most for the kind: how long an HTTP monitor has been up or down (with the cause while it fails) and the last 24 hours as hourly bars, or the days until a certificate or domain expires with its thresholds on a timeline.
HTTP monitors get two more cards:
- Uptime: uptime over the last 7, 30 and 90 days and a custom range within those 90 days, each with its incidents and time down; MTBF and MTTR for a chosen period; and a bar with one segment per UTC day. Click a day to open the checks of that day.
- Response time: one line over the last hour (every check), 24 hours, 7 days or 30 days (hourly or daily averages), with the average, minimum and maximum under it. Click a point to open the check log for its window.
Every kind gets Latest incidents with an Export logs button, and History with two views: Status changes ("Down for 3m", the cause beside it, with links to the check that caused it and to the incident it opened) and All checks (every result, 7 days by default). Status changes are kept 1 year; raw check results about 30 days. A certificate renewal a check saw is listed under the status it happened in.
The sidebar holds the kind's panels (an HTTP monitor's Expiry watches and Latest check, an SSL monitor's Certificate details, a domain monitor's Registration details) and Monitoring: who gets the alerts, how often and from where it checks, and when it was created.
Uptime and availability
Uptime is (ok + warning) / (ok + warning + critical): a slow answer is still an answer, an inconclusive check counts neither way. Without any checks there is no number ("No data"), never a fake 100%.
Downtime per day is an estimate: the share of critical checks among the conclusive ones times the minutes the day's checks cover, capped at the day so far. Days are UTC. SSL and domain monitors have no uptime, only counts: they show days until expiry instead.
Response-time breakdown
The Latest check card shows where an HTTP check's time went: DNS,
connect, TLS, waiting for the first byte and reading the response, plus
the time spent on earlier redirect hops. The phases describe the final
request (the last hop). A phase that didn't happen reads n/a: an IP
address has no DNS, plain HTTP no TLS. Every check opens a fresh
connection, so the timings are those of a new visitor.
Export
Export logs on the Latest incidents card downloads a CSV of the
last 90 days: the monitor's incidents, its status changes and its
certificate renewals, oldest first, with ISO 8601 UTC times. Columns:
type, started, ended, duration_seconds, status, severity,
cause, detail. It is built in the browser from what the page loaded.
Settings and Alerts
Settings is the same form as New monitor, with every section open, plus Delete monitor. Saving a settings section replaces it as a whole; a settings change that alters what the monitor checks ends its open incident. If someone else changed the monitor while you were editing, the form keeps your edits and offers to load the newer version.
Alerts sets who gets this monitor's alerts and when; see Alerts.
Getting started
Create your first monitor, add and verify an alert channel, make it the default, send a test alert, and gate a deploy from CI. About five minutes.
HTTP monitors
Every setting of an HTTP monitor. Method, headers with secrets, body, accepted statuses, timeout and slow threshold, redirects, TLS verification, the keyword check, and the certificate and domain expiry watches.