RMON
- How to set up your Time zone
- How to create a Telegram bot and use it with RMON
- How to create a Slack APP and use it with RMON
- How to create PagerDuty Integration key and use it with RMON
- Notifications and alerting
- Status pages
- Security checklist
- Company sign-in with OIDC
- Get started with the RMON API
- Backup and recovery
- How to use groups and roles
- How to change user settings
Servers
Troubleshooting
Start with the action that failed and use the matching section below. Record the exact error and its time before retrying. After correcting the cause, verify the same operation and a fresh monitoring result.
Record the affected action
Note the RMON and agent versions, active group, affected check and location, and whether the problem affects one location or all of them. For installation, retain the failed task message. For monitoring, open the check's history and read the latest timestamp and error. An old UP result cannot confirm current health.
Find the relevant log
Use these log commands on the host running the affected service. Match the log time with the task or check failure. A failed SSH action belongs to RMON's operation logs; an agent execution or delivery failure belongs to the agent host; notification delivery errors may be on the result server.
Cannot sign in or open a page
Scroll horizontally to view the full table.
| Symptom | What to do | How to confirm |
|---|---|---|
| Browser reports an untrusted or wrong-host certificate | Use the configured public hostname. Have the administrator install the matching certificate and full chain, or distribute the intended private CA trust. | The RMON sign-in page opens over HTTPS without a certificate warning on the user's device. |
| Sign-in page does not open / gateway error | Check web-service status and proxy logs using the service checks below. Confirm the public address resolves to this installation. | The sign-in page responds at the configured address. |
| Company sign-in fails | Use a local administrator account to compare the provider callback URL with the exact RMON URL, review the user/domain policy and group mapping, and check certificate trust. | A company test user signs in with the expected role and group. |
| A menu, host or check is missing | Open User settings and verify Current group. Ask an administrator to check membership, role and resource sharing. | The intended resource appears after selecting the authorized group. |
Database access or ownership error
- Check that the installation is using its existing database and configuration. In Docker, inspect the mount sources in your deployment settings before running any initialization command.
- For SQLite, verify read/write access to the database file and its directory for the RMON service account. Keep the database and accompanying files together.
- For an external database, have the database administrator verify the host, port, account, database name and permissions.
- If saved SSH credentials can no longer be read after a move, restore the matching original application keys from the same installation's backup.
Follow the existing-installation migration guide for Docker ownership and mounts. Do not run init to work around a missing database mount. Verify sign-in and access to existing checks before resuming monitoring.
Agent installation or reconfiguration fails
Scroll horizontally to view the full table.
| Reported failure | Corrective action |
|---|---|
| Operation stays pending | Allow up to 30 seconds for an idle queue to pick up the task. If it remains pending, check the operations service (native: rmon-operations) and its database access using the log guide. A previous operation on the same server must finish first. Inspect the existing task before submitting it again. |
| SSH timeout, refusal or authentication error | Use Servers → Actions → Check SSH. Follow the SSH error table with the saved address, port and credential. |
| Sudo password or permission error | Verify non-interactive sudo for the SSH account. While signed in as that account, sudo -n id -u should print 0. |
| Docker or package download fails | Check package-source access, DNS, outbound proxy and available disk space on the agent host. Confirm that the selected image is available to the installation. |
| Certificate path is outside the group directory | Use the exact directory shown under Agent connections for the server owner's group. Move the intended file there and update the field. |
| Certificate file missing or unreadable | Check the file in RMON's mounted storage, its path and service-account permissions. An existing file on a workstation or an unmounted host directory is insufficient. |
| Existing client pair is incomplete | Restore the missing matching file or supply both replacement client files. Do not remove the remaining key just to trigger generation. |
| Operation is already running / deployment lock | Check the existing task and host state before retrying. Do not launch a second operation on the same host or remove a lock while work is running. |
After correction, retry once and wait for the final status. Then review the applied mode on the card and create a check on that agent. If the browser loses contact while an operation runs, inspect the existing task and service first; a browser timeout does not prove the host operation stopped.
Agent runs but results do not update
- Open the check, note the latest result time and confirm it is enabled and not past its expiration date.
- Confirm the affected agent is enabled and the check is assigned to the intended location. A region selection may use one agent in that region; use the actual assigned agent.
- Inspect the agent log around the expected run time. Distinguish failure to reach the monitored target from failure to send results.
- Check that the agent can reach the RMON website and every
master_ipreceiver onmaster_port. For Docker, replace mistaken loopback addresses with the reachable host/service address. - Compare the agent's last applied Result delivery mode with the receiver configuration. Apply saved changes with Reconfigure.
- After restoring access, watch the check for new timestamps over at least two configured intervals.
After an agent starts, it requests its check assignments from RMON. If RMON is unavailable, it retries automatically with a delay that increases to at most five minutes. Restore website access and inspect the agent log before restarting it again.
If only one location fails, compare that location's DNS, route, firewall and target access with a working location. If all locations stop together, check the common receiver and web services. A failed management probe and failed result delivery are separate symptoms: review both connections.
HTTPS and mTLS certificate errors
Scroll horizontally to view the full table.
| Symptom | Check | Successful result |
|---|---|---|
| Unknown issuer / unable to verify certificate | Use the correct Trusted CA bundle and have the receiver present its complete certificate chain. | HTTPS verification succeeds with trust checks enabled. |
| Hostname mismatch | Compare the receiver address with the names/IPs covered by its certificate. Correct the address or issue the appropriate certificate. | The certificate covers the exact connection address. |
| Expired / not yet valid | Check certificate dates and host clocks. Renew the certificate or correct time synchronization. | All relevant certificates are within their validity period. |
| Client certificate does not match key | Supply both files from the same issued pair; do not mix a new certificate with an unrelated old key. | mTLS reconfiguration passes credential validation. |
| Receiver rejects the client certificate | Confirm client-authentication usage and that the receiver trusts the issuing CA. | The connection with the intended client certificate succeeds. |
| Receiver must require a client certificate | Configure the receiver to require mTLS. HTTPS with optional client authentication does not satisfy the selected mode. | Authorized clients connect and a connection without a client certificate is rejected. |
After replacing files, reconfigure the agent and confirm a fresh result. Do this even when the filenames are unchanged. Follow the connection walkthrough rather than disabling certificate validation to hide the failure.
Check an unavailable service
On the RMON Docker host, run these commands from its deployment directory using the same Compose file selection as the installation:
docker compose ps --all
docker compose logs --since=15m --tail=100 web scheduler operations proxyFor a receiver in the same project, also inspect docker compose logs --since=15m --tail=100 server. On an agent host, inspect sudo docker ps -a --filter name=rmon-agent and sudo tail -n 100 /var/log/rmon/rmon-agent.log.
For a native receiver, use systemctl status rmon-server --no-pager and journalctl -u rmon-server --since "15 minutes ago" --no-pager. Resolve the reported configuration, certificate or permission problem before restarting. A running process must also pass the check-result verification.
A notification is missing
- Open Channels, test the saved destination and confirm receipt at the provider.
- If it fails, correct credentials, destination, permissions or outbound access. For email, also check SMTP and spam filtering.
- If it succeeds, edit the check and verify the intended destination is selected on Notifications rather than Disabled.
- Read alert history to confirm a relevant incident occurred. Check retries, priority and the condition that should cause the alert.
- Use the failure-and-recovery exercise on a disposable check to verify the complete route.
RMON 1.4 no longer provides browser notifications. Select and test the external destinations required by each check; see notification setup.
An update fails
Stop at the failed step and preserve its error. Confirm which image/version is selected and whether the database update completed. Do not run an old version against a partially updated database. Use the restore procedure with matching configuration, database and application keys.
Before retrying, confirm backup availability, storage space, file ownership and access to the intended version. After updating or restoring, check sign-in, existing checks, fresh results and notification delivery.
Package source or image access fails
RMON packages are public and require no repository account, password or access key. Check the repository configuration, supported release and architecture, DNS and outbound access. For container images, check the exact registry path and tag; credentials are needed only if your installation uses a private registry. Keep signature and certificate verification enabled. If the source remains unavailable, send support the version reference and sanitized error.