Anatomy of a schedule: name, timezone, crons

Outcome

By the end of this lesson, you will be able to create a minimal schedule and explain the role each field plays in execution.

1. Concept

A schedule has four fields. Only the name is required to save, but a schedule that does something needs all four.

Learn the four and everything else in this track, the templates, the groups, the overrides, is a layer sitting on top of them.

The four fields

NAME                 Required. Human-readable, unique within the org,
                     up to 255 characters
                     e.g., "dev-and-staging-business-hours"

DESCRIPTION          Optional. One line of context for teammates
                     e.g., "Stops dev and staging non-prod Mon-Fri 8pm,
                            starts 8am ET. Excludes ephemeral envs."

TIMEZONE             Picked from a dropdown of IANA names
                     e.g., "America/New_York" rather than "EST"

CRONS                Start and stop cron expressions, each with an action.
                     You do not type them: you paint running hours on the
                     weekly grid and ZopNight writes the crons (L3)

Why timezone matters

“8 PM” on its own does not name a moment. Eight in the evening where?

So ZopNight asks for a place rather than an offset: Europe/London, Asia/Kolkata, America/Los_Angeles. This is the IANA format, the standard list of timezone names that operating systems and programming languages all share. Naming the place rather than the offset buys three things:

• The schedule fires at the same clock time all year, because the place knows when its own clocks change
• A team in India and a team in California each get their own hours, in their own time
• The 24-hour grid is drawn in the schedule’s time, not in whatever time the person looking at it happens to be in

The common mistake is to set a schedule in UTC for a team that does not live in UTC. It looks right for months, then the clocks change and everything fires an hour out. Use the team’s own timezone and it never happens.

Why multiple crons

A schedule typically has at least two crons:

SCHEDULE: dev-business-hours
  Timezone: America/New_York

  Cron #1   "0 8 * * 1-5"           Action: start    "Weekdays 8 AM"
  Cron #2   "0 20 * * 1-5"          Action: stop     "Weekdays 8 PM"

A more uneven week needs more crons. A schedule that runs 7am to 7pm on weekdays and 10am to 2pm on Saturday has four: a start and a stop for the weekday block, and a start and a stop for Saturday. The grid writes exactly as many as the pattern needs, and no redundant ones: a weekend that is already off after Friday’s 7pm stop gets no extra “stop” cron.

Nothing else lives on the schedule

The only optional field is the description. A schedule has no tags, no notification settings and no override limit. Notifications are set up as subscriptions on a channel (M1.6), and overrides are separate objects, each with its own mandatory expiry time (M1.5 L4: Override expiry and conflicts).

What the schedule does NOT carry

Three things are deliberately separate from the schedule:

1. Resource attachment: covered in L5. The schedule says when; the attachment says to what. Many resources can share one schedule.
2. Group attachment: also L5. Same principle: a schedule attaches to groups for cascade application.
3. Action sequencing: covered in M1.4 (groups). Sequencing lives on the group, not the schedule.

The separation lets schedules be reused across many resources and groups without duplication.

The create flow

T+0       Schedules page → New Schedule
T+5 sec   Type a name and description
T+10 sec  Pick timezone (IANA format from the dropdown)
T+15 sec  Pick a template, or paint running hours on the weekly grid
T+20 sec  ZopNight writes the start and stop crons from the grid
T+25 sec  The hint below the grid shows the next trigger ("Starts in 3h 20m")
T+30 sec  Save → schedule is created
T+35 sec  Schedule is empty (no resources yet). Next: attach resources (L5)

Less than a minute to create the schedule. Attachment is a separate step.

The grid is the editor

The create dialog is built around a 24-hour weekly grid. You click or drag cells to mark them RUNNING or STOPPED, and the form turns the painted pattern into crons. What you see on the grid is what the schedule will do. (Full coverage in L3.)

Update and delete

A schedule can be edited at any time. Editing affects future firings; past firings are not retroactive.

Deleting a schedule requires name-confirmation (typing the schedule name into a confirmation field) to prevent accidents. The name-confirmation pattern is the same one used for destructive operations elsewhere in the product.

2. Demo

A complete schedule, created step by step:

CREATE SCHEDULE
─────────────────────────────────────────────────────────
Name:         dev-and-staging-eu-business-hours
Description:  Starts dev and staging non-prod Mon-Fri 8am UTC+1,
              stops 8pm UTC+1. EU team coverage.
Timezone:     Europe/London

Granularity:  [Hour ▾]        Template: [Apply a template... ▾]

WEEKLY GRID (paint RUNNING cells; crons written for you:
             "0 8 * * 1-5" start, "0 20 * * 1-5" stop)
  Mon ▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░  (ON 8am-8pm)
  Tue ▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░
  Wed ▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░
  Thu ▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░
  Fri ▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░
  Sat ░░░░░░░░░░░░░░░░░░░░░░░░  (OFF: last stop on Fri 8pm)
  Sun ░░░░░░░░░░░░░░░░░░░░░░░░

ESTIMATED SAVINGS   64%     ACTIVE HOURS   60h     INACTIVE HOURS   108h

Starts in 3h 20m  (Mon 08:00)

[Cancel]                                              [Save schedule]

The grid, the savings percentage and the next-trigger hint together give the user confidence before saving.

3. Hands-on (6 min)

Create your first schedule (use a sandbox if production resources are at risk):

1. Open Schedules → New Schedule.
2. Name it something clear: "non-prod-business-hours-test".
3. Description: one sentence.
4. Pick your team's IANA timezone.
5. On the grid, paint Monday to Friday, 08:00 to 20:00, as RUNNING.
6. Leave everything else STOPPED.
7. Read the next-trigger hint under the grid.
8. Note the savings percentage (about 64%).
9. Save. The schedule is created but empty.

For now, do not attach resources. We'll cover attachment in L5.

4. Knowledge check

Q1

The only field a ZopNight schedule must have before it will save is:

A. Its timezone
B. Its name
C. Its description
D. At least one cron

Q2

A schedule’s timezone is set to “EST” (not “America/New_York”). The most likely consequence:

A. Fails to save: IANA format is required
B. Saves, but ignores daylight saving
C. Saves but fires twice
D. Saves but fires at midnight always

Q3

A schedule has two crons: “0 8 * * 1-5” start and “0 20 * * 1-5” stop. The same schedule is attached to 47 resources. The total schedule executions per week:

A. 47
B. 2
C. 2 × 5 × 47 = 470 actions per week (2 crons × 5 weekdays × 47 resources)
D. 10 firings per week, counting both of the crons together each week

5. Apply

Schedule creation is in:

• Schedules page → New Schedule
• The timezone comes from a dropdown of IANA names, and the grid writes the crons
• The next-trigger hint updates as you paint the grid
• The schedule page shows the estimated savings percentage

For complex schedule design patterns (rolling environments, freeze windows, demo prod), see Schedule design patterns.

Related lessons

• L2: Cron expressions without tears (next)
• L3: The 24-hour weekly grid
• L4: Four schedule templates

Glossary terms touched

Schedule · Cron expression