Moorfox
Alerts: thresholds, and routing them per tag
Alerting in Moorfox is two decisions kept deliberately apart. What counts as a problem is set per type: CPU, memory, disk, offline and Windows crashes each have their own threshold, and each can be turned off entirely.
Who hears about it is set per tag. One rule per tag, each with its own address, plus a default for everything no tag rule matched. That is how one dashboard covers customers who ring different desks.
The Alerts page
Everything currently breached, and the recent history behind it. The sidebar carries a count of the open ones, so a page you are not looking at still tells you.
Most alerts resolve themselves: the CPU comes back down, the disk gets cleared, the machine reconnects. Those close on their own and the Resolved column says cleared. The Resolve button is for the ones that cannot clear themselves, crash alerts above all: a blue screen is an event, not a state, so nothing will ever declare it over except a person. Resolving by hand records who did it.
Thresholds, one per type
Settings in the sidebar, under Manage. Admin only, and the thresholds apply to every device in the organisation.
Each row is independent. Clearing the checkbox on the left switches that type off completely, which is the right answer for a fleet where, say, disk is watched by something else already.
| Type | What you set | When it fires |
|---|---|---|
| CPU | A percentage (50 to 100) and a window in minutes | Only if the level holds for the whole window. A brief spike during a backup is not an alert. |
| Memory | A percentage and a window in minutes | Same rule as CPU: sustained, not momentary. |
| Disk | A percentage | Immediately. A full disk does not become less full by waiting, so there is no window to set. |
| Offline | A number of minutes | When the agent has been out of contact for that long. Set it above your reboot and patch windows or you will page yourself every Tuesday. |
| Windows crashes | On or off | Immediately, on a blue screen. Nothing to tune: it either happened or it did not. |
The sustained window on CPU and memory is the setting that decides whether alerting is useful or ignored. Ten minutes above 90% is a machine in trouble; ten seconds above 90% is a machine doing its job.
One machine that is not like the others
The thresholds above are the organisation's, and most fleets want exactly that. The exception is the box whose normal is not everybody else's normal: a build server that sits pinned at 100% CPU because that is its job, a backup target that runs its disk close to full on purpose, a laptop that is legitimately off for a fortnight. Left on the org thresholds, machines like that page you every day until you stop reading any alert at all.
So a device can carry its own thresholds. Open the device, go to its Alerts tab, and click Alert settings. By default the dialog shows the organisation's numbers, read-only, resolved for that machine's class: a server and a workstation have separate offline thresholds, and this shows you the one that actually applies. Customise for this device turns those same values into a form you can edit, seeded from what governs the machine today, so switching to custom changes nothing until you change a number. Use the organisation defaults puts it back.
An override answers when to alert, and only that. Which types are emailed, and which addresses they route to, stays on the organisation's Settings page for every device, so raising one machine's CPU threshold never quietly takes it off somebody's routing.
This is the first thing to reach for when alerts start getting ignored. One noisy machine trains people to filter the whole folder, and the fix is nearly always a threshold that suits that machine rather than a rule that suits none of them.
The email switch is per type too
Every row carries its own email toggle on the right. That is a separate question from whether the alert exists: a type can be watched, appear on the Alerts page and drive the sidebar count, without anybody being emailed at three in the morning.
The usual shape of this is crashes and offline by email, CPU and memory on the dashboard only.
Routing: a different address per tag
Below the thresholds sit Tags and Alert emails, in that order and for a reason: on this page a tag's job is to be the thing a rule routes on.
Each row is a switch and an address. Turning the row on is the decision; typing the address carries it out, which is why the field stays disabled until the switch is on. Several addresses go in one field separated by commas.
| Rule | Covers |
|---|---|
| Default | Every device that no tag rule below matched. This is your catch-all, and leaving it off means some machines page nobody. |
| One row per tag | Every device carrying that tag. |
The important part, and the one people get wrong: a device carrying several tagged rules is emailed to all of them. The rules are not a first-match cascade. The default is the only one that behaves that way, and only applies when nothing else did.
So a server tagged both production and Northbay Dental pages your on-call address and the customer's desk, from one alert, with no duplicate rules to maintain.
Addresses have to confirm
An address outside your organisation is sent a confirmation link before it can ever be paged, and a rule pointing at an unconfirmed address is saved switched off rather than refused. The card says so at the point of saving, and offers a Send verification button beside the address.
This is not friction for its own sake. Routing is the one place in Moorfox where filling in a form aims outbound mail at somebody else's inbox, so the inbox gets a say. Your own users are already proven by redeeming their invitation and need no click.
Worth knowing
- A message goes out when an alert opens, not when it clears. No all-clear emails.
- Deleting a tag takes its alert email rule with it. The confirmation says so before you agree.
- If outbound email is not configured on the server, the card says so in place of pretending the rules work.
- A row left blank is simply not a rule, so clearing an address is how you remove one.
Next: how to put tags on machines in the first place, or the activity log.
Moorfox is remote monitoring and management without the enterprise tax.
One agent, one dashboard, remote desktop and a real terminal on every machine you look after.