1. The development cycle

The cycle from one stable version of Checkmk to the next takes around twelve to eighteen months. It begins following the release of the preceding version – for example 1.6.0 – with the start of development of the new features for the coming version – for example 2.0.0. This development takes place on the main development branch (master).

After about six to nine months the first innovation version will be created. This will be maintained for a short time in its own branch.

Following the creation of two to four innovation versions the beta phase commences – for which a branch will also be split off on which the new stable version will be finalized and later maintained. On the main branch the preparation for the next cycle will then begin.

As well as on the main development branch, daily intermediate versions (daily builds) are also created on the stable branch – which offer access to new features or bug fixes. An graphic representation of the whole process for the 1.6.0 version looks somewhat like the illustration below:

development cycle

2. Versions and editions

2.1. Daily builds from the master

CEE On the development branch (in the Git’s version control this is referred to as the ‘master’), Checkmk’s future is being developed. So that developers, users and other interested parties can at any time get an impression of the current state of the software, every day between 0:00 and 6:00 Middle European Time an installations package for all supported Linux distribution versions will be created. These packages are called daily builds, Git snapshots or developer versions, and they represent the exact state of the software’s development at the start of every day.

The daily builds will naturally often contain some bugs, since it contains a more or less ‘random’ snapshot of the current state of the software. In contrast to the innovation and stable versions, daily builds also generate no new development branch, and thus cannot be patched by us. The only way to correct an error in a daily build, is to replace it with a newer daily build which may have it’s own problems. For this reason a daily build should never be used for a production environment.

Nevertheless, the daily builds are very useful if you as a user wish to try out new features in real time. This is especially applicable if you yourself have commissioned us to develop the feature!

Our support is also happy to help with difficulties with daily builds, but under the following restrictions:

  • We can only help if the daily build is no more than a week old.

  • We cannot create patches.

  • Daily builds are not covered by break-fix support.

2.2. Innovation versions

CEE Innovation versions are a special feature of the CEE Checkmk Enterprise Editions and give you the possibility to use new and interesting features in the software long before the next stable version is released. The innovation versions represent a compromise between stability and new features.

As a rule the first innovation version becomes available about half a year after the last stable release. Over the following 1-2 months, 3-4 releases will be produced, each identified in sequence by an i number (e.g., 1.6.0i2). Similarly to stable versions, these will also be actively maintained – but only for a limited time of around 1-2 months, which is then followed by a similar period of passive maintenance. Patches of i-versions can be recognized by a p-suffix, e.g., 1.6.0i2p1.

Innovation versions are not covered by break-fix support.

2.3. Beta versions

The release of a new stable version, (e.g. 2.0.0), begins with a beta phase. In order to correct all errors, and to make the software production ready, an additional stable branch containing only error corrections will be split off. Development of features for future versions continues in parallel on the main branch.

On the stable branch a series of beta versions – identified by a lowercase b in their names – will be published, (e.g., 2.0.0b1, 2.0.0b2, etc.). This occurs every two weeks or so, as long as no serious errors are identified.

2.4. Stable version

Following the beta phase, a stable version is released – for example, 2.0.0. Now that many more users are trying out the new release, further problems will be identified that were not noticed during the beta phase. These will be corrected by a series of patch releases (2.0.0p1, 2.0.0p2, etc.). The time intervals between these patches will initially be quite short (around a week), and later they will be much longer (a few months).

In addition to the master, daily builds are also published on the stable branch, which provide prompt bug fixes. These carry the name of the branch, plus the date, e.g., 2.0.0-2021.03.12.

You can use these versions in production, providing you observe the following:

  • Only use a daily build on the stable branch if it solves a serious problem.

  • Update to the next patch version as soon as it becomes available.

2.5. Editions and their identifying suffixes

When you display the version of a Checkmk site with the omd version command, you will see a further suffix, which the OMD views as a part of the version number:

OMD[mysite]:~$ omd version
OMD - Open Monitoring Distribution Version 2.0.0.cre

This suffix enables the same versions of various Checkmk editions to be distinguished. This makes it possible to have, for example, version 2.0.0 of the CRE Checkmk Raw Edition and the CSE Checkmk Enterprise Standard Edition, installed simultaneously. This is in fact sometimes very sensible – namely if you wish to migrate from the CRE to the CEE. The following suffixes are possible:


CRE Checkmk Raw Edition


CFE Checkmk Enterprise Free Edition


CSE Checkmk Enterprise Standard Edition


CME Checkmk Enterprise Managed Services Edition

3. Maintenance and support

3.1. Active maintenance

We will actively maintain this stable version with patch releases. How long this happens depends on when the follow-up version is released and thus becomes the new stable version. The rule as of version 1.6.0 is: The active maintenance ends for a version 6 months after the release of the new version. Since for the stable version the follow-up version has not yet been released, the planned release date serves to determine the support periods.

This means that two versions are served in parallel with patch releases for 6 months: the stable version and the previous (oldstable) version. An overview of the support periods can be found at the end of this article.

3.2. Passive maintenance

After the end of the active maintenance, the stable branch moves to a passive maintenance phase, which generally lasts for another year.

During this time we generally only fix errors when commissioned by customers using support tickets through a support contract. If you have a contract with the break-fix option, such error fixes are covered.

Bug fixes during the passive maintenance phase generate further patch releases, which are of course also beneficial to users without a support contract.

3.3. Support periods of the stable versions

CEE Since daily builds and beta versions are only recommended for testing purposes and the support periods are correspondingly short, only the current and former stable versions are listed in the following table. Whether your version is still being maintained and when it has reached or will reach its end-of-life can be seen from the following table:

VersionRelease dateEnd of active maintenanceEnd of passive maintenance













For older versions we highly recommend updating.

On this page