Outcome
By the end of this lesson, you will be able to read the 24-hour weekly grid and spot gaps and overlaps in a schedule before save.
| Prerequisites | L1, L2 |
| Time | 10 minutes |
1. Concept
A cron expression is exact and tells you nothing about what it looks like in practice.
You can write three of them, read them back, be entirely satisfied, and find out on Saturday that the machines ran all weekend. That is why ZopNight builds schedules on the grid itself: you paint the hours a resource should run, at hour, 30-minute or 15-minute granularity, and the form writes the crons for you. Quick-selects (Night, Business, Evening, Weekends, Clear All) and the templates from L4 fill common patterns in one click. What you see is what will fire, before you press save, not afterwards on the bill.
What the grid shows
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23Mon ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Tue ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Wed ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Thu ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Fri ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Sat ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░Sun ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░
LEGEND: ██ RUNNING ░░ STOPPEDThis is the visual representation of 0 8 * * 1-5 (start) + 0 20 * * 1-5 (stop). Paint RUNNING from 8 AM to 8 PM on weekdays and leave everything else STOPPED, and those are exactly the two crons the form writes.
In the product the grid responds to the mouse. Click or drag to flip cells. Hover any square and it tells you the day, the time and the state, for example Tue 14:30 - RUNNING.
The three mistakes it catches
Failure 1: The unintended gap.
Cron: 0 8 * * 1-5 (start) + 0 18 * * 1-5 (stop). Intent: “weekdays 8am-6pm.”
Grid:
... 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20...Mon ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░...ON 8 AM through 6 PM. That’s 10 hours per weekday, not 12. If the intent was 8 AM through 8 PM, the schedule stops too early. The grid reveals this at a glance. The fix: paint 18:00 to 20:00 as RUNNING, and the stop cron becomes 0 20 * * 1-5.
Failure 2: The redundant cron.
Cron #1: 0 8 * * 1-5 (start), Cron #2: 0 20 * * 1-5 (stop), Cron #3: 0 9 * * 1-5 (start).
The third one does nothing. It starts a resource at 9 AM that the first one already started at 8. You cannot build this in the grid: the form rewrites the crons from the painted cells, so a second start inside a block that is already running is dropped. It can only come from a schedule created through the API or an assistant, and the next time anyone saves that schedule from the grid, the extra cron disappears.
Failure 3: The weekend trap.
Cron #1: 0 8 * * 1-5 (start), Cron #2: 0 20 * * 1-5 (stop).
Mon-Fri ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ░░ ░░ ░░ ░░Sat ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░Sun ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░ ░░This is correct AS LONG AS the resource was OFF on Friday at 8 PM. If a manual start fired on Friday 9 PM (for an overnight build), the schedule has no stop cron between Friday-stop (already passed at 8 PM) and Monday-start (next firing): so the resource stays running all weekend.
You cannot fix this by painting: a weekend that is already STOPPED writes no extra stop cron. The fix is in how the resource was started. For an overnight build, use a force-on override with an end time (M1.5) instead of a manual start. When the override expires, ZopNight sends the resource back to the state the schedule says it should be in.
Reading the grid for one specific firing
Hovering over any cell in the grid (in the product) shows that cell’s state:
Tue 14:30 - RUNNINGTo see when the schedule will next act, read the hint under the grid in the form: it names the next state change and how far away it is, for example “Stops in 5h 30m”, with the absolute time beside it.
What the grid does NOT show
Two limitations:
- It does not show overrides. Force-on / force-off overrides (M1.5) can suspend the schedule’s normal pattern for a window. The grid shows the schedule’s intent, not the runtime state.
- It does not show resource-specific differences. If a resource has its own override, the grid still shows the schedule’s default pattern. Per-resource state is in the resource detail page.
The grid shows the schedule’s pattern. The Inventory page is where you see actual current state.
2. Demo
A real schedule design session, with the grid catching a bug:
INTENT: Stop dev outside business hours and weekends, EU timezone.
ATTEMPT 1 (template): Template "Business Hours (Weekdays 9AM-6PM)" Grid shows: RUNNING 09:00-18:00 weekdays. Weekend all STOPPED. But: the EU team works until 21:00. The grid makes the gap obvious: three red hours every weekday evening.
ATTEMPT 2 (paint the gap): Drag across 18:00-21:00, Monday to Friday Grid shows: RUNNING 09:00-21:00 weekdays. Weekend all STOPPED. Crons written: "0 9 * * 1-5" start, "0 21 * * 1-5" stop Estimated savings: 64% (60 running hours of 168)
Save. The schedule covers the intent fully.Without the grid, the 18:00 stop would have been invisible until the EU team lost their dev environment mid-evening. The grid catches the gap before save.
3. Hands-on (6 min)
For your test schedule from L1:
1. Open the schedule in edit mode.2. View the 24-hour weekly grid.3. Hover over cells across the week. Confirm the state matches intent.4. Look specifically for: - Gaps you didn't intend - Weekend behavior (especially if your schedule has weekday-only hours)5. If you find a gap, paint the missing cells.6. Read the next-trigger hint under the grid.7. Save the corrected schedule.4. Knowledge check
Q1
The 24-hour weekly grid renders the schedule in:
A. UTC always
B. The schedule’s IANA timezone; so a team in Asia/Kolkata sees the grid relative to their local time, not UTC
C. The viewer’s own local browser timezone, rather than the schedule’s own configured timezone setting
D. America/New_York
Show answer
Correct: B. Grid renders in the schedule’s IANA timezone. Crons are interpreted in that timezone; the grid displays the same way.
Q2
A schedule has 0 8 * * 1-5 start and 0 20 * * 1-5 stop. A resource is running Friday at 9 PM (it was started manually). The schedule next fires Monday at 8 AM. Between Friday 8 PM and Monday 8 AM, the resource state:
A. Stops automatically Friday at 8 PM
B. Stops at noon Sunday
C. Stays running
D. Stops at midnight automatically
Show answer
Correct: C. No stop cron fires between Friday 8 PM (already passed) and Monday 8 AM. The scheduler acts only at cron times; it does not track state between them, so a manual start outside the running window persists until the next stop. For an overnight build, a force-on override with an end time is the safer tool.
Q3
A schedule created through the API has weekday start crons at 08:00 and 09:00 and one stop at 20:00. Someone opens it in the grid editor and saves. What happens to the crons?
A. Both start crons are kept exactly as they were
B. The form rewrites the crons and drops the 09:00 start
C. The save fails with a cron overlap error for that weekday
D. The 08:00 start is dropped and only the 09:00 start is kept
Show answer
Correct: B. The grid paints RUNNING from 08:00 to 20:00, and the form writes crons from the painted cells: one start at 08:00, one stop at 20:00. The 09:00 start was a no-op on an already-running resource, so nothing about the schedule’s behavior changes.
5. Apply
The grid is a first-class part of the schedule create / edit flow:
- Schedule create dialog: paint the grid; the form writes the crons
- Schedules page: open any saved schedule to see its grid