How do I set up monitoring for a system?

Requires Pro

Quick answer

In the Monitoring module, click “Add manual system”, give it a name and an address (host/IP), and choose the checks: ping reachability, a TCP port and/or an HTTP(S) URL. Notory then checks the system regularly, server-side. Open its history by clicking the system name — selectable via 1 h, 24 h and 7 d.

Prerequisites

Monitoring is part of the Operations module and available from the Pro tier.

Open the dialog. Click “Add manual system” in the top right.
Define the system and its checks. Fill in the dialog:
- Name (required) — a recognizable name, e.g. “Webserver DMZ”.
- Address (Host / IP) — e.g. 192.168.1.10 or web.example.com.
- Checks:
  - Ping reachability — Is the host reachable via ping? (default: on)
  - TCP port — an optional port for a connection test, e.g. 443.
  - HTTP(S) URL — an optional URL; a successful response counts as up.
Screenshot pending monitoring-system-01 'Add manual system' dialog with Name, Address and the Ping, TCP port and HTTP URL checks

Creating a manual system with ping, TCP and HTTP checks.
Save. The system appears in the list — initially with status Unknown, until the first server-side check runs.
View the history. Click the system name. The history opens on the right with the 1 h / 24 h / 7 d range switcher and the Resource usage chart (CPU, memory, disk — for agent systems). For manual systems, the history reflects reachability instead.

Screenshot pending monitoring-system-02 Detail view of a system with the time range switcher and the Resource usage chart

The system history with the time range switcher (1 h / 24 h / 7 d).

Create a system — POST /api/v1/monitoring/hosts (scope write). name is required:

curl -X POST https://demo.notory.io/api/v1/monitoring/hosts \
  -H "Authorization: Bearer inv_dein_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Webserver DMZ",
    "address": "web.example.com",
    "check_ping": true,
    "check_tcp_port": 443,
    "check_http_url": "https://web.example.com/health"
  }'

{
  "id": "hs_9a8b…",
  "tenant_id": "3d9b0c12-…",
  "name": "Webserver DMZ",
  "host_type": "manual",
  "address": "web.example.com",
  "check_ping": true,
  "check_tcp_port": 443,
  "check_http_url": "https://web.example.com/health",
  "enabled": true,
  "current_status": "unknown",
  "last_checked_at": null,
  "last_seen_at": null,
  "created_at": "2026-07-08T10:15:00Z"
}

Read the history — GET /api/v1/monitoring/hosts/{id}/metrics?range=1h. Allowed ranges: 1h (raw data), 24h (5-minute aggregates) and 7d (hourly aggregates):

curl -H "Authorization: Bearer inv_dein_token" \
  "https://demo.notory.io/api/v1/monitoring/hosts/hs_9a8b.../metrics?range=24h"

Possible errors: 400 (unknown range), 401, 403 (the Operations module is not in your tier or no write access), 404 (system not found), 422 (validation, e.g. a port outside 1–65535).

What happens behind the scenes?

Server-side checking: Manual systems (host_type: manual) are checked by a periodic job from the outside (TCP connect / HTTP GET), which writes reachability and, where applicable, HTTP latency into the time series.
Detail metrics come from the agent: CPU, memory and disk curves are only populated by an agent system. A manual system shows reachability instead of utilization.
Optional asset link: A system can reference an asset (asset_id); if the asset is deleted, the system remains (the link is set to null).
Retention: Raw data and aggregates are trimmed by retention jobs once they expire. Tenant isolation and audit logging apply as everywhere else.