Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Monit sends an alert every time the monit daemon is stopped or started. This is obnoxious and not useful information.

According to the docs, I set:

set alert but not on { instance }

...which should send alerts to that e-mail, unless they are in the "instance" category, which is defined as starts/stops.

However, I still get alerts generated. This is super annoying. Clearly I must be missing something.

We're running Monit 5.2.4

share|improve this question
Is this covered by this question? – ewwhite Aug 12 '13 at 21:24

I'm using Monit version 5.2.5 and using the following has stopped monit alerts coming through

set alert not {instance}

share|improve this answer

Monit can, according to the documentation generate a number of alerts:

Event:     | Failure state:              | Success state:
action     | "Action done"               | "Action done"
checksum   | "Checksum failed"           | "Checksum succeeded"
bytein     | "Download bytes exceeded"   | "Download bytes ok"
byteout    | "Upload bytes exceeded"     | "Upload bytes ok"
connection | "Connection failed"         | "Connection succeeded"
content    | "Content failed",           | "Content succeeded"
data       | "Data access error"         | "Data access succeeded"
exec       | "Execution failed"          | "Execution succeeded"
fsflags    | "Filesystem flags failed"   | "Filesystem flags succeeded"
gid        | "GID failed"                | "GID succeeded"
icmp       | "Ping failed"               | "Ping succeeded"
instance   | "Monit instance changed"    | "Monit instance changed not"
invalid    | "Invalid type"              | "Type succeeded"
link       | "Link down"                 | "Link up"
nonexist   | "Does not exist"            | "Exists"
packetin   | "Download packets exceeded" | "Download packets ok"
packetout  | "Upload packets exceeded"   | "Upload packets ok"
permission | "Permission failed"         | "Permission succeeded"
pid        | "PID failed"                | "PID succeeded"
ppid       | "PPID failed"               | "PPID succeeded"
resource   | "Resource limit matched"    | "Resource limit succeeded"
saturation | "Saturation exceeded"       | "Saturation ok"
size       | "Size failed"               | "Size succeeded"
speed      | "Speed failed"              | "Speed ok"
status     | "Status failed"             | "Status succeeded"
timeout    | "Timeout"                   | "Timeout recovery"
timestamp  | "Timestamp failed"          | "Timestamp succeeded"
uid        | "UID failed"                | "UID succeeded"
uptime     | "Uptime failed"             | "Uptime succeeded"

We were able to fix this on our side by setting (addresses changed to protect the innocent):

SET ALERT ON { invalid, nonexist, timeout, resource, size, timestamp}
SET ALERT ON {action, permission, pid, ppid, instance, status}

This successfully routes the messages to the adresses we care about. You can set them globallly or locally, but our alerts are just global.

The subheadings under SERVICE TESTS at: correspond fairly neatly to the types above.

For each scheduled process or feature of your server, you should be able to come up with what matters to you in plain English, and match that desire to one of the tests mentioned in SERVICE TESTS. For example, if I'm running Apache, I know that I care about:

  • Is the PID in the PID file still running? (nonexist)
  • Did the PID change without my knowledge? (pid)
  • Is the service responding in a timely fashion to a restart? (timeout)

For a custom daemon that polls, I may care about whether the log file is getting updated with status messages regularly (timestamp).

share|improve this answer
How do you tell what you care about? I wasn't able to find good documentation on what those actions actually mean. For example, "uptime" seems pretty useful, but you don't have it on your list. – dfrankow Aug 7 '13 at 18:50
I'll edit my answer to comment. – brokenbeatnik Aug 12 '13 at 21:14

Simply tell it to knock it off after a certain number of retries in N time period according to these examples.

share|improve this answer
This is not the notification of a given watched process or service stopping or starting (which is news) but of the monit daemon itself stopping/starting, which is always intentional and not news. – Winfield Apr 20 '11 at 13:00
Ooooh, what if you remove the "set alert" line in global, and put explicit alerts in your service stanzas? – Ben Lutgens Apr 20 '11 at 13:12
this works better.. just set the alert emails in the checks.. remove the global one. – Mike Dec 13 '11 at 23:49
up vote 1 down vote accepted

I was unable to fix this within monit and had to build a layer of processing on the monit e-mail to filter out these monit instance notifications before delivery, by intercepting them.

We're using pager duty to accumulate and dispatch notices from monit and several other systems, so in this case I added a filtering rule on the Monit service using a subject based regex to filter out monit instance notice e-mails.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.