This document describes the current stable version of Celery (5.6). For development docs, go here.

# `celery.schedules`

Schedules define the intervals at which periodic tasks run.

exception celery.schedules.ParseException

  Raised by `crontab_parser` when the input can’t be parsed.

class celery.schedules.crontab(minute: int | str | Iterable[int] = '*', hour: int | str | Iterable[int] = '*', day_of_week: int | str | Iterable[int] = '*', day_of_month: int | str | Iterable[int] = '*', month_of_year: int | str | Iterable[int] = '*', **kwargs: Any)

  Crontab schedule.

  A Crontab can be used as the `run_every` value of a periodic task entry to add crontab(5)-like scheduling.

  Like a cron(5)-job, you can specify units of time of when you’d like the task to execute. It’s a reasonably complete implementation of cron’s features, so it should provide a fair degree of scheduling needs.

  You can specify a minute, an hour, a day of the week, a day of the month, and/or a month in the year in any of the following formats:

  minute

    - A (list of) integers from 0-59 that represent the minutes of an hour of when execution should occur; or

    - A string representing a Crontab pattern. This may get pretty advanced, like `minute='*/15'` (for every quarter) or `minute='1,13,30-45,50-59/2'`.

  hour

    - A (list of) integers from 0-23 that represent the hours of a day of when execution should occur; or

    - A string representing a Crontab pattern. This may get pretty advanced, like `hour='*/3'` (for every three hours) or `hour='0,8-17/2'` (at midnight, and every two hours during office hours).

  day_of_week

    - A (list of) integers from 0-6, where Sunday = 0 and Saturday = 6, that represent the days of a week that execution should occur.

    - A string representing a Crontab pattern. This may get pretty advanced, like `day_of_week='mon-fri'` (for weekdays only). (Beware that `day_of_week='*/2'` does not literally mean ‘every two days’, but ‘every day that is divisible by two’!)

  day_of_month

    - A (list of) integers from 1-31 that represents the days of the month that execution should occur.

    - A string representing a Crontab pattern. This may get pretty advanced, such as `day_of_month='2-30/2'` (for every even numbered day) or `day_of_month='1-7,15-21'` (for the first and third weeks of the month).

  month_of_year

    - A (list of) integers from 1-12 that represents the months of the year during which execution can occur.

    - A string representing a Crontab pattern. This may get pretty advanced, such as `month_of_year='*/3'` (for the first month of every quarter) or `month_of_year='2-12/2'` (for every even numbered month).

  nowfun

    Function returning the current date and time (`datetime`).

  app

    The Celery app instance.

  It’s important to realize that any day on which execution should occur must be represented by entries in all three of the day and month attributes. For example, if `day_of_week` is 0 and `day_of_month` is every seventh day, only months that begin on Sunday and are also in the `month_of_year` attribute will have execution events. Or, `day_of_week` is 1 and `day_of_month` is ‘1-7,15-21’ means every first and third Monday of every month present in `month_of_year`.

  classmethod from_string(crontab: str) → crontab

    Create a Crontab from a cron expression string. For example `crontab.from_string('* * * * *')`.

        ┌───────────── minute (0–59)
        │ ┌───────────── hour (0–23)
        │ │ ┌───────────── day of the month (1–31)
        │ │ │ ┌───────────── month (1–12)
        │ │ │ │ ┌───────────── day of the week (0–6) (Sunday to Saturday)
        * * * * *

  is_due(last_run_at: datetime) → tuple[bool, datetime]

    Return tuple of `(is_due, next_time_to_run)`.

    If `beat_cron_starting_deadline` has been specified, the scheduler will make sure that the last_run_at time is within the deadline. This prevents tasks that could have been run according to the crontab, but didn’t, from running again unexpectedly.

    Note

    Next time to run is in seconds.

    SeeAlso:

      `celery.schedules.schedule.is_due()` for more information.

  remaining_delta(last_run_at: ~datetime.datetime, tz: ~datetime.tzinfo | None = None, ffwd: type = <class 'celery.utils.time.ffwd'>) → tuple[datetime, Any, datetime]
  remaining_estimate(last_run_at: ~datetime.datetime, ffwd: type = <class 'celery.utils.time.ffwd'>) → timedelta

    Estimate of next run time.

    Returns when the periodic task should run next as a `timedelta`.

class celery.schedules.crontab_parser(max_: int = 60, min_: int = 0)

  Parser for Crontab expressions.

  Any expression of the form ‘groups’ (see BNF grammar below) is accepted and expanded to a set of numbers. These numbers represent the units of time that the Crontab needs to run on:

      digit   :: '0'..'9'
      dow     :: 'a'..'z'
      number  :: digit+ | dow+
      steps   :: number
      range   :: number ( '-' number ) ?
      numspec :: '*' | range
      expr    :: numspec ( '/' steps ) ?
      groups  :: expr ( ',' expr ) *

  The parser is a general purpose one, useful for parsing hours, minutes and day of week expressions. Example usage:

      >>> minutes = crontab_parser(60).parse('*/15')
      [0, 15, 30, 45]
      >>> hours = crontab_parser(24).parse('*/4')
      [0, 4, 8, 12, 16, 20]
      >>> day_of_week = crontab_parser(7).parse('*')
      [0, 1, 2, 3, 4, 5, 6]

  It can also parse day of month and month of year expressions if initialized with a minimum of 1. Example usage:

      >>> days_of_month = crontab_parser(31, 1).parse('*/3')
      [1, 4, 7, 10, 13, 16, 19, 22, 25, 28, 31]
      >>> months_of_year = crontab_parser(12, 1).parse('*/2')
      [1, 3, 5, 7, 9, 11]
      >>> months_of_year = crontab_parser(12, 1).parse('2-12/2')
      [2, 4, 6, 8, 10, 12]

  The maximum possible expanded value returned is found by the formula:

  exception ParseException

    Raised by `crontab_parser` when the input can’t be parsed.

  parse(spec: str) → set[int]

celery.schedules.maybe_schedule(s: int | float | timedelta | BaseSchedule, relative: bool = False, app: Celery | None = None) → float | timedelta | BaseSchedule

  Return schedule from number, timedelta, or actual schedule.

class celery.schedules.schedule(run_every: float | timedelta | None = None, relative: bool = False, nowfun: Callable | None = None, app: Celery | None = None)

  Schedule for periodic task.

  Parameters:

    - run_every (float, timedelta) – Time interval.

    - relative (bool) – If set to True the run time will be rounded to the resolution of the interval.

    - nowfun (Callable) – Function returning the current date and time (`datetime`).

    - app (Celery) – Celery app instance.

  property human_seconds: str
  is_due(last_run_at: datetime) → tuple[bool, datetime]

    Return tuple of `(is_due, next_time_to_check)`.

    Notes

    - next time to check is in seconds.

    - `(True, 20)`, means the task should be run now, and the next

        time to check is in 20 seconds.

    - `(False, 12.3)`, means the task is not due, but that the scheduler should check again in 12.3 seconds.

    The next time to check is used to save energy/CPU cycles, it does not need to be accurate but will influence the precision of your schedule. You must also keep in mind the value of `beat_max_loop_interval`, that decides the maximum number of seconds the scheduler can sleep between re-checking the periodic task intervals. So if you have a task that changes schedule at run-time then your next_run_at check will decide how long it will take before a change to the schedule takes effect. The max loop interval takes precedence over the next check at value returned.

    Scheduler max interval variance

    The default max loop interval may vary for different schedulers. For the default scheduler the value is 5 minutes, but for example the https://pypi.org/project/django-celery-beat/ database scheduler the value is 5 seconds.

  relative: bool = False
  remaining_estimate(last_run_at: datetime) → timedelta
  property seconds: int | float

class celery.schedules.solar(event: str, lat: int | float, lon: int | float, **kwargs: Any)

  Solar event.

  A solar event can be used as the `run_every` value of a periodic task entry to schedule based on certain solar events.

  Notes

  Available event values are:

  > - `dawn_astronomical`

  > - `dawn_nautical`

  > - `dawn_civil`

  > - `sunrise`

  > - `solar_noon`

  > - `sunset`

  > - `dusk_civil`

  > - `dusk_nautical`

  > - `dusk_astronomical`

  Parameters:

    - event (str) – Solar event that triggers this task. See note for available values.

    - lat (float) – The latitude of the observer.

    - lon (float) – The longitude of the observer.

    - nowfun (Callable) – Function returning the current date and time as a class:~datetime.datetime.

    - app (Celery) – Celery app instance.

  is_due(last_run_at: datetime) → tuple[bool, datetime]

    Return tuple of `(is_due, next_time_to_run)`.

    Note

    next time to run is in seconds.

    See also

    `celery.schedules.schedule.is_due()` for more information.

  remaining_estimate(last_run_at: datetime) → timedelta

    Return estimate of next time to run.

    Returns:

      when the periodic task should

        run next, or if it shouldn’t run today (e.g., the sun does not rise today), returns the time when the next check should take place.

    Return type:

      timedelta