Monit is a lightweight open-source monitoring and self-healing utility for Unix and Linux servers. It periodically checks processes, files, directories, file systems, network hosts and system resources against rules written in a simple control file, and when a check fails it can restart a service, run a script or send an alert without human intervention.
In the topic of services & processes, Monit sits between a pure process supervisor and a full monitoring system. It does not have to be the parent of the processes it watches, and it does not collect long-term metrics. Its strength is local, rule-based recovery: noticing that a daemon has died, stopped answering on its port or grown beyond a memory limit, and fixing that on the spot.
How Monit checks and repairs services
Monit runs as a daemon that wakes up in fixed polling cycles, typically every 30 to 120 seconds, set with set daemon 60 in the control file monitrc. In each cycle it evaluates every configured check in order. A process check finds the running process through a PID file or a name pattern, then reads its state from the operating system.
Each check can carry conditions and actions. A condition such as if failed port 80 protocol http then restart combines a test with a reaction, and a cycle count such as for 3 cycles prevents action on a single transient failure. Monit also tracks restart attempts over time, so a rule like if 5 restarts within 5 cycles then unmonitor stops a crash loop instead of restarting forever.
Because Monit observes processes from the outside, it needs the start and stop programs for each service, usually the init system commands. This loose coupling lets it watch daemons started by systemd, SysV scripts or other tools, but it also means detection is only as fast as the polling interval.
What Monit can monitor
Monit offers several check types, each with its own tests. The table below lists the main ones and what they are typically used for.
| Check type | Typical tests | Common use |
|---|---|---|
| check process | Running state, CPU, memory, child count, port response | Web servers, databases, queue workers |
| check file | Existence, checksum, size, timestamp, permissions | Configuration integrity, stale output files |
| check filesystem | Space and inode usage, read-only state | Disk full prevention |
| check host | ICMP ping, TCP and protocol tests | Remote dependencies such as an upstream API |
| check system | Load average, CPU, memory, swap | Overall server health |
| check program | Exit status of a custom script | Any test Monit does not support natively |
Protocol tests are a particular strength. Monit can speak HTTP, SMTP, MySQL, PostgreSQL, Redis, SSH and other protocols at a basic level, so it detects a hung process that still exists but no longer answers requests, which a simple liveness check would miss.
Monit compared with other process supervisors
Several tools keep services running, and they differ mainly in whether they own the process and how quickly they react. The comparison below places Monit among its neighbors.
| Tool | Relationship to process | Reaction speed | Distinctive feature |
|---|---|---|---|
| Monit | External observer by polling | One polling cycle | Resource and protocol tests with actions |
| systemd | Parent via cgroups | Immediate on exit | Restart policies and watchdog timer integration |
| Supervisord | Parent of child processes | Immediate on exit | Simple management of non-daemonizing programs |
| PM2 | Parent for Node.js apps | Immediate on exit | Cluster mode and application-level features |
In practice these tools complement each other. A common pattern lets systemd handle the restart policy for an unexpected exit, while Monit adds checks that systemd does not perform by itself, such as response time on a port, memory growth or disk space. Running two tools that both try to restart the same service, however, can produce conflicting restarts, so responsibilities must be divided clearly.
Configuring Monit in practice
A good Monit configuration is short, specific and tested. Each rule should reflect a real failure mode, and every threshold should be based on the normal behavior of the service. The decision table below shows typical choices.
| Situation | Recommended rule | Reason |
|---|---|---|
| Service crashes occasionally | Restart on missing process | Fast recovery without manual work |
| Service hangs but stays alive | Restart on failed protocol test for 2 to 3 cycles | Catches deadlocks, tolerates brief spikes |
| Slow memory leak | Restart above a memory limit for several cycles | Buys time until the leak is fixed |
| Disk filling with logs | Alert at about 80 percent, act at about 90 percent | Leaves room for human decisions |
| Repeated crash loop | Unmonitor after several restarts | Prevents restart storms and preserves evidence |
Monit also provides a small embedded web interface and a command-line client. Commands such as monit status, monit summary and monit reload show the state of each check and apply configuration changes, and monit -t validates the control file syntax before a reload. The web interface should listen only on localhost or be protected with strong credentials and TLS.
Limitations and common mistakes
Monit is effective on a single machine, but it is not a replacement for central monitoring. It has no built-in long-term metric storage and no dashboards across many servers, so most teams pair it with a central system for trends and paging.
- Automatic restarts can hide real bugs. Every restart should also trigger an alert or log entry so that the root cause is investigated.
- Stale PID files lead to false status. The service must write and remove its PID file reliably, or the check should match by process name.
- Overly tight thresholds cause restarts during normal peaks. Cycle counts and realistic limits avoid this.
- Monit itself must be supervised. Running it under systemd ensures it returns after a crash or reboot.
- Restart order matters when services depend on each other. The
depends onstatement keeps a service dependency chain consistent.
Explained without jargon
Monit is a small caretaker program that lives on a server. Every minute or so, it checks the important programs. Are they still running? Do they still answer? Are they using too much memory or disk space?
When something is wrong, it follows instructions written in advance. It can restart the program, run a repair step or send a message to the people in charge. Think of a night guard with a checklist. The guard can reset a tripped switch, but also knows when to stop and call for help.
A typical use case
A small hosting provider runs PHP-FPM, Nginx and MariaDB on each of its web servers. Occasionally PHP-FPM workers lock up under heavy traffic: the process still exists, but pages stop loading, and the init system sees nothing wrong.
The administrators add a Monit rule that requests a lightweight status page through Nginx every 60 seconds and restarts PHP-FPM after two failed checks. A second rule restarts it if total memory exceeds a set limit for five cycles, and every action sends an email. After deployment, lockups that once caused outages of 20 minutes or more are resolved in about two minutes, and the alert history gives developers the timestamps they need to find the underlying bug.