Forge Home


Setup monit


4,788 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 1.2.1 (latest)
  • 1.2.0
  • 1.1.2
  • 1.1.1
released Mar 3rd 2019
This version is compatible with:
  • Puppet Enterprise 2023.7.x, 2023.6.x, 2023.5.x, 2023.4.x, 2023.3.x, 2023.2.x, 2023.1.x, 2023.0.x, 2021.7.x, 2021.6.x, 2021.5.x, 2021.4.x, 2021.3.x, 2021.2.x, 2021.1.x, 2021.0.x, 2019.8.x, 2019.7.x, 2019.5.x, 2019.4.x, 2019.3.x, 2019.2.x, 2019.1.x, 2019.0.x, 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
  • Puppet >= 4.0.0
  • , FreeBSD, , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'puppetfinland-monit', '1.2.1'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add puppetfinland-monit
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install puppetfinland-monit --version 1.2.1

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



puppetfinland/monit — version 1.2.1 Mar 3rd 2019

Build Status


A general-purpose monit module for Puppet. Support for M/Monit is available but not tested on recent platforms.

Module usage

The simplest way to use this module:

class { '::monit':
  email => '',

The email parameter can be omitted if global variable $::servermonitor is defined.

By default monit monitors CPU usage, load averages and memory, plus disk space and inode consumption on the root filesystem. The pre-configured thresholds can be customized as needed.

This module also includes additional defines:

Both ::monit::filesystem and ::monit::directory support parameter called $exec_cmd, which can be used to run a command if the check fails. A fairly typical use-case is cleaning up unused kernels in Ubuntu:

::monit::filesystem { 'boot-filesystem':
  path     => '/boot',
  exec_cmd => 'apt-get -y autoremove',

For this particular use-case, though, there's a sepate convenience class:

include ::monit::boot

The class runs a platform-specific autoremove task.

This module also supports creating monit fragments from other Puppet modules:

Any virtual ::monit::fragment resource tagged with 'default' is realized in the main ::monit class. The postfix module uses this feature:

Also, if a File resource is tagged with 'monit' it will be realized as well; the use-case for this is adding test scripts for monit from other modules.

It is also possible to reuse a single template from several places, passing variables to it as a hash. For example:

class myclass::daemon1 {

  $vars = { 'service_name'  => $::myclass::params::daemon1_service_name,
            'pidfile'       => $::myclass::params::daemon1_pidfile,
            'service_start' => $::myclass::params::daemon1_service_start,
            'service_stop'  => $::myclass::params::daemon1_service_stop, }

  ::monit::fragment { 'daemon1.monit':
    ensure     => 'present',
    basename   => 'myservice',
    modulename => 'myclass',
    identifier => 'daemon1',
    vars       => $vars,
    epp        => true,

In this case you'd have an EPP template in myclass/templates/myservice.monit.epp that uses the parameters along these lines:


check process <%= $service_name %> with pidfile <%= $pidfile %>
    start program = "<%= $service_start %>"
    stop  program = "<%= $service_stop %>"
    alert <%= $::monit::email %> with reminder on 480 cycles

You could then pass the ::monit::fragment a different set of variables to make it configure some other service.