How Matmon works – laid open, connection by connection.
One server you run yourself, probes and agents that call it from the outside in, and a cloud you can leave out. Here is what travels where.
Connections and data flows
Every connection is opened from the inside out. No inbound ports at remote sites. Select a connection for direction, protocol, port and payload.
Monitored networks
- Web UI and REST API
- Sensor scheduler
- Alerting and escalation
- History and reports
- Syslog / trap receiver
- Backups
All state in one data volume (/app/data). No cloud dependency.
Users and services
Transmitted
- Heartbeat every 30 s
- Polls its sensor assignments, run-now and discovery jobs
- Measurement results
Not transmitted
- No inbound connection to the probe site
- No connection to Matmon Cloud
Details
- Auth:
X-Matmon-Probe-Token - Primary unreachable: results buffered on disk (7 days / 100,000), replayed with original timestamps
Transmitted
- Same protocol as a probe: heartbeat, assignments, results
- Local metrics: CPU, memory, disks
- Update check against the Primary (hourly)
Not transmitted
- No inbound port, no WinRM or SSH required
- No connection to Matmon Cloud
Details
- Enrolment:
matmon-agent enroll --url … --code …(one-time code); plain HTTP to a public host is refused - Windows service (LocalSystem), systemd, launchd
- Self-contained binary: win-x64, linux-x64, linux-arm64, macOS
Transmitted
- Polling: ICMP, HTTP(S), DNS, TCP, SNMP, vendor APIs (Proxmox, Hyper-V, Synology …)
- Inbound: syslog UDP/TCP 514, SNMP traps UDP 162 – only with the receiver enabled
Not transmitted
- No software on the device
- Credentials not stored in plaintext – DataProtection-encrypted, also in backups
Details
- Devices in a remote network are polled by the probe in that network
- Receivers run on the Primary, a probe or an agent
Transmitted
- Web UI, REST API, wallboards (read-only links)
- Web push to the installed PWA
Not transmitted
- No external identity provider required – local accounts work offline
Details
- No built-in TLS: terminate HTTPS at a reverse proxy (
Matmon__TrustedProxies) - Access from outside without port forwarding: Full Access via Matmon Cloud
Transmitted
- Alert messages via SMTP
- Webhooks: ntfy, Pushover, Gotify, Telegram, Teams, Slack, Discord, custom
Not transmitted
- No relay through Matmon servers – except the “Matmon Cloud” sender
Details
- SMS and voice only via the Matmon Cloud sender, critical alerts only
Transmitted
- Heartbeat every 30 s: version, host name, counts (sensors, probes, maps, alerts), probe name / version / state
- Cloud sender: recipient and alert text; SMS / voice: summary only
- Backups (manual or scheduled): configuration, secrets encrypted; history optional
- Full Access: UI proxied through a WebSocket tunnel (wss) opened by the Primary
Not transmitted
- Measurement values in the heartbeat
- Credentials in plaintext
- Inbound connections to the Primary
- Traffic from probes or agents
Details
- Auth:
X-Matmon-Instance-Tokenafter a PKCE claim - Separate switches: alert relay, Full Access, backup target
- Link off: monitoring continues; SMS / voice, remote access and cloud backups unavailable
What goes to the cloud – and when
Only if you connect an instance. Taken from the code, not from a brochure.
| What | When | Contents | Switch |
|---|---|---|---|
| Heartbeat | every 30 s | version, host name, counts of sensors, probes, maps and open alerts; names, versions and online state of your probes | disconnect |
| Alerts by SMS, call, cloud e-mail | when a rule uses the Matmon Cloud sender | recipient address or number, alert text (SMS and calls: a short summary, critical alerts only) | alert relay switch |
| Report e-mails | when a report uses the cloud sender | recipients and the report PDF | choose another sender |
| Backups | when you start or schedule one | configuration with secrets encrypted; history only if you include it; optional passphrase | backup job: off / local / cloud |
| Remote access | while you use it | the pages you open – through a tunnel your Matmon opens | Full Access switch |
| Partner reports and template exports | when your service partner asks for them | availability report (PDF); templates without credentials | disconnect |
| Windows updates and agent packages | update check, agent download | an anonymous download from cloud.matmon.eu/feeds (GitHub as fallback) – also without a cloud link | Matmon__UpdateFeedUrl |
Never: measurements on the heartbeat, readable passwords or device credentials, anything from probes or agents directly.
Your monitoring data stays where it is measured.
Matmon is a monitor you run yourself. These things hold without any setting:
Monitoring, alerts by e-mail and webhook, local accounts and the licence check all run offline.
Probes and agents connect outbound. Even remote access through the cloud is a tunnel your Matmon opens.
No analytics, no phoning home. The cloud link is opt-in and every part of it has a switch.
Device credentials are stored encrypted – in backups too. A backup passphrase seals a package for another machine.
Everything Matmon keeps lives in one volume. Moving to a new server means copying it.
A signed licence token, checked on your server, with a grace period if the cloud is out of reach.
Try it on your own server
One compose file or one Windows setup – and you see every connection yourself.