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 2.1.0 – with the start of development of the new features for the coming version – for example 2.2.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

Each Checkmk edition is available in different versions, i.e. at different stages of development. You will therefore also encounter different variants of the term version here in the User Guide.

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.

2.2. Innovation versions

CEE Innovation versions are a special feature of the commercial editions and give you the possibility to use new and interesting features in the software long before the next stable version is released. They represent a compromise between stability and new features. However, innovation versions are optional and are not provided in preparation for each stable version.

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., 2.0.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., 2.0.0i2p1.

2.3. Beta versions

The release of a new stable version, (e.g. 2.2.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.2.0b1, 2.2.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, also called major version, is released – for example, 2.2.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 versions, sometimes also called patch releases (2.2.0p1, 2.2.0p2, etc.). The time intervals between these patch versions 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.2.0-2023.03.30.

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.

3. 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.2.0p1.cre

This suffix enables the same versions of various Checkmk editions to be distinguished. This makes it possible to have, for example, version 2.2.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 Raw Edition to one of the commercial editions. The following suffixes are possible:


CRE Checkmk Raw Edition


CSE Checkmk Enterprise Standard Edition


CSE Checkmk Cloud Edition


CME Checkmk Enterprise Managed Services Edition

4. Maintenance and support

4.1. Active maintenance

We will actively maintain this stable version with patch versions. 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 product lifecycle.

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

4.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.

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

4.3. Product lifecycle of the stable versions

CEE Since daily builds and beta versions are only recommended for testing purposes and the product lifecycle is 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:

Version Release date End of active maintenance End of passive maintenance



6 months after release of 2.3.0[1]










For older versions we highly recommend updating.

[1]. Currently, no release date has been set.
On this page