RMON 1.4: monitoring that asks better questions

The server is running. The CPU is relaxed. The dashboard is green. Meanwhile, a customer is refreshing a checkout page with the determination usually reserved for a broken lift button.

Those observations can all be true. A running process is one piece of evidence; a service that works from the networks people use is another. RMON is built to collect that second kind of evidence and turn it into something your team can act on.

Ask the question your users would ask

RMON runs availability and synthetic checks from agents you place in your infrastructure. A check might request an API response, resolve a DNS record, connect to a TCP port, test SMTP or RabbitMQ, or send a Ping. Results, history and notification destinations are managed through the web interface.

The useful question depends on the service. For an internal tool, it might be “Can our branch office reach the login page?” For an API, it might be “Does this endpoint return the expected status and JSON value?” A successful Ping answers a narrower question. It has never promised to approve a purchase order.

You choose where RMON and its agents run. That makes private networks, office connections and customer-facing routes practical monitoring locations. It also leaves you in charge of updates, access, backups and certificate renewal. Self-hosting comes with keys to the building and responsibility for the plumbing.

Make a useful check easy to describe

In RMON 1.4, creating or editing a check follows three steps: Check, Settings and Notifications. Choose the target and locations, define the expected behavior, then decide who needs to hear about a problem.

For HTTP, “healthy” can include an accepted status code, required content, a JSONPath value, response headers, certificate validation and a response-time threshold. The new SSL policy also lets you require HTTP or HTTPS at the final URL. These conditions give a green result a specific meaning.

Give the result a protected journey

An agent checks a service and sends the result to an RMON result receiver. RMON 1.4 exposes HTTP, HTTPS and HTTPS with mutual TLS as explicit choices when installing or reconfiguring an agent.

With mTLS, the agent verifies the receiver’s certificate and the receiver requires a trusted client certificate. Administrators can supply client credentials or configure generation for agents. The card shows the last applied delivery mode, verification time and pending changes, so a saved preference is less likely to be mistaken for a completed rollout.

This protects result delivery. It does not turn every RMON connection into mTLS: agent management still has its own HTTP connection and network restrictions, while installation and service actions use SSH. The connection guide explains those boundaries.

Make routine operations easier to follow

Agent operations are queued, and queued work survives service restarts. Operations for the same server run in order. A browser timeout is therefore a reason to inspect the existing task, not an invitation to click Restart with increasing enthusiasm.

RMON also gives teams groups and roles, company sign-in, notification channels and public status pages. These solve different parts of daily operations: who can change a check, who receives its incidents and which availability information customers should see. Configure each deliberately; a status page is not a substitute for an alert route.

Start with one service you care about

Choose one dependency, describe a healthy response and add a representative location. Verify a fresh result, deliberately fail a disposable test and confirm that recovery reaches the intended destination. Expand after that loop works.

RMON’s value is in that loop: a concrete question, evidence from a useful location and a response that reaches the right person. Start with the setup guide, then create your first check. Review installation options and available versions before upgrading an existing deployment.