The Scheduler service

This page is also available in: Deutsch, Русский

The Scheduler is the new maintenance system developed specifically for subscribers to give control over server maintenance and help solve common issues like disk utilization and service restarts.

Moreover, you may choose between different stability branches for your homeserver.

How to start

Start a chat with and send help to get instructions

NOTE: that bot works only for customers, so it won’t work for other users.


Scheduler supports 4 work modes, you may use all of them at the same time. Rule of thumb - you should have at least recurring maintenance to be sure that your server is updated and protected.


The run mode will immediately run a command , for example:

ssh.INFO [] disk usage: 48%

See the full list of available commands here .


The schedule mode will schedule a command execution for a specific date and time (UTC), for example, if you want to perform maintenance of your server on July 1st at 5pm UTC:

and on the July 1st at ~5:30pm UTC (maintenance takes some time) you will receive the following message:

Yes, there is no mistake - the schedule mode just schedules the run mode for a specific date and time in the future


The recurring mode sets the recurring schedule mode to a specific weekday and time. By default, you will have the maintenance command set to a random weekday and time ( maintenance service), so instead of manual runs or schedules every time you want to schedule some command that mode will automatically create corresponding schedule to run the command you choose on specific weekday and time. For example, you want to get server maintenance every Friday at 3pm UTC:

and every Friday at ~3:30pm UTC (maintenance takes some time) you will receive the following message:

NOTE: you may set only 1 recurring schedule per command (eg you can have only 1 recurring maintenance), so multiple recurring configurations of the same command (e.g. recurring maintenance Friday 15:00 and recurring maintenance Monday 17:00) will replace each other and you will end up with only one recurring maintenance configuration (the last one) – on Monday 17:00 UTC


List mode just lists your runs (executed commands and result of execution), schedules, and recurring schedules, useful in case you want to check something.


* 2022-06-12 16:36: run ping
* 2022-05-30 22:01: run maintenance
* 2022-06-19 16:03: run restart slack failed: exit status 1
* 2022-06-27 16:00: run ping (recurring)
* 2022-07-01 17:00: run ping

NOTE: the (recurring) suffix above indicates that the given task was automatically scheduled, because there’s a (weekly) recurring schedule for it. Only the first (nearest) future recurrence date is indicated.

* Monday 16:00: run ping



That command will check server reachability and disk utilization, useful when you’re applying a new firewall or just want to be sure that you have free space to upload 5GB of cat photos.


ssh.INFO [] disk usage: 48%


That command triggers the maintenance process, which takes 15-30 minutes to complete. You can learn more on the services page



That command restarts a systemd service, useful when you see that a bridge is hung and not responding. It has an internal mapping between “human-friendly” service names and actual service names, so if you want to restart the facebook bridge, you can use run restart facebook instead of run restart matrix-mautrix-facebook (though, the latter will work, too)


NOTE: for the schedule and recurring modes, the restart command requires the service name to be after the date/weekday and time, for example: schedule restart 2022-07-01 17:00 slack or recurring restart Monday 17:00 slack

Stability branches

The Scheduler was developed with the assumption that some customers may prefer stable, but slower updates, and others may prefer unstable, but much faster updates to get the freshest possible versions as soon as possible.

You may choose the stability branch that will suit your needs. If you want to switch the stability branch of your homeserver, just let us know by sending us a message .

stable (default)

stable, as the name suggests is our more-stable (more tested) stability branch, compared to fresh . It’s typically a few days (up to a week) behind our fresh branch.

With the default stability branch, we collect updates of the components during the week and first test them on developers’ servers, on open-source community members’ servers, and on customer servers which are explicitly opted into using the fresh stability branch. It’s only after all this testing that do we publish these updates in the stable branch, so you can install them during maintenance and be sure they won’t break anything.

stable is the default stability branch that we use on all customer servers, except for customers who have explicitly asked us to use fresh.

fresh (testing)

This branch receives updates as soon as possible, so you get the freshest updates used by developers and the open-source community. Such updates may sometimes contain breaking changes, but we usually prepare workarounds and migrations before publishing them. Use this (fresh) stability branch if you’d like to get updates as soon as possible (up to 1 week earlier than stable), at the expense of a higher potential for breakage.

We have a special room where updates are published almost in real-time.