Interval Scheduling

An interval schedule is easy to understand and a perfect choice for most situations.

The logic is simple: there is a fixed period between the start time of successive checks.

If a monitor is configured with an interval of 5 minutes, and a check starts running 11:22:33, the next check will start at 11:27:33. The duration of each check is not important here, the interval is only between start times.

If you need your monitor to execute according to the real-world time - such as every hour on the hour, or every Sunday at 3am - you should use a crontab schedule.

We highly recommend reading the section on potential gotchas, to be aware of a couple of possibly-unintuitive side effects of this scheduler.

Limits

The interval value provided can be any value, so long as the equivalent number of seconds is:

• a whole number (e.g. 0.5 minutes is allowed, 0.99 minutes is not)
• no more than 2592000 (30 days, in seconds)
• no less than the minimum allowed by your plan (see table below).

There is no difference between numerically-equivalent values. For example, 0.5 minutes produces identical behaviour to 30 seconds.

Using an interval of less than 60 seconds will cause the monitor to consume additional monitor credits. See this page for more details.

Minimum Intervals

Potential Gotchas

Delays & Cancellation

There is a subtle difference between how scheduling works with intervals and crontabs. An interval schedule sets the time between the start of each execution, whereas crontabs specify the exact time at which it should start.

This usually achieves a similar effect, but a notable difference occurs when resuming an existing monitor. To illustrate it, let us consider an example.

Monitor A is set to run with a crontab expression of */5 * * * *, which means to trigger every 5 minutes, at exact 5-minute-multiples past the hour.

It is created at 13:05:00, and runs immediately as this time matches the crontab expression. It next runs at 13:10:00, then 13:15:00. At 13:15:46 the monitor is manually paused.

If it is resumed before 13:20:00 - the next potential run time - it will execute then as planned. It will be as if it was never paused - no execution delayed or cancelled. However, if it is still paused at 13:20:00 then it will not run again until resumed.

This occurs, and the monitor is not resumed until 13:21:37. It does not run immediately; the 13:20:00 execution was missed and is simply lost. The monitor does not execute again until 13:25:00, then 13:30:00, and so on.

There has been no permanent change to the schedule, but a check instance was skipped.

Let us now consider the case of an interval scheduler.

Monitor B is set to run on a 5-minute interval. It is created at 13:05:00, as before. It runs immediately, as is always the case with a new interval-controlled monitor.

The monitor next runs at 13:10:00, then 13:15:00. At 13:15:46 the monitor is manually paused, as before.

If it is resumed before 13:20:00 - the next potential run time - it will execute then as planned. It will be as if it was never paused - no execution was delayed or cancelled. However, if it is still paused at 13:20:00 then it will not run again until resumed.

Up until now, the behaviour has been identical to the crontab monitor, but we are about to diverge.

As before, it is not resumed until 13:21:37. Unlike with the crontab schedule, Monitor B runs immediately as the previous execution was more than 5 minutes ago, which is the configured interval. The next run will then be 13:26:37, then 13:31:37, and so on.

We can see that there is a permanent change to the schedule. The interval setting is still applied consistently - subsequent checks are scheduled 5 minutes after the start of the last - but the exact execution times have slipped.

In short, interval-controlled jobs may execute later originally planned, if they were paused (or otherwise unable to fire) at that point. Moreover, they have no fixed or absolute schedule, only operating relative to the start of the last check.

Server Clocks

All of our monitoring servers are configured for UTC, and the software performing time calculations is similarly configured to use this timezone.

This should not affect interval schedules, as the next execution is typically simply a fixed period of time after the last. Thus, the result would be the same in any timezone.

The sole exception to this is around leap seconds, during which we use smearing to avoid any leap second-related inconsistencies. Consequently, our clocks are up to 500 milliseconds away from true (UTC) time during the 12 hours either side of a leap second.

You should also be aware that the actual time a monitor check beings may be a few seconds after the scheduled time. This is due to a variety of factors, most notably network latency.

The delay is usually only a few milliseconds, and we guarantee to never start before the scheduled time (subject to the leap smear exception noted above).

We are not aware of any situation in which any of these timing details has caused a problem, but we mention them here for the sake of transparency.