Generating a timetable

Once your Periods, Teachers, Rooms, Subjects, Classes, and Lessons are set up, the Generate page is where you actually run the solver against that data.

Queuing a request

Clicking Generate Timetable reads your current data straight from the database (whatever's saved at that moment — there's no separate "draft" state) and sends it to /api/solve, which creates a request row and hands it off to a background worker. You get a request ID back immediately; the actual solve happens asynchronously.

A generation works in two steps within your plan's time limit: first it looks for any schedule that satisfies every hard constraint, then it spends the rest of the time improving that schedule on your soft constraints. If time runs out while it's still improving, you still get the valid schedule it already found - it just may not be as well arranged as it could be.

Check Feasibility runs only that first step: it stops at the first valid schedule instead of optimizing soft constraints, so it's a good way to sanity-check your hard constraints (locks, unavailability, tags, capacity) without waiting for a full optimization pass. A feasibility check that completes doesn't produce a viewable timetable or a Save Timetable button — it only tells you whether one exists.

Request statuses

The Current Request card polls every 3 seconds and shows one of:

• PENDING — queued, waiting for a worker slot to open up.
• PROCESSING — the solver is actively running (this can take anywhere from seconds to a few minutes, depending on how much data you have). The card shows which step it's on, how long that step has taken, and how long the whole run has been going:
  • Checking your data — the quick checks for mistakes that rule out every timetable (see When generation fails). Usually over in a moment.
  • Preparing the search — setting up the search. Larger schools take longer here, and this step doesn't count towards your plan's time limit.
  • Searching for a timetable (Checking whether a timetable exists for Check Feasibility) — looking for any timetable that meets every rule, for at most your plan's time limit.
  • Improving the timetable (Generate only) — a valid timetable has been found; the rest of the time limit goes to arranging it better on your soft constraints.
  • Working out why — the search proved no timetable exists, and the solver is working out which of your settings are to blame. This can take up to your plan's time limit again (at least 30 seconds), which is why a failed run can take longer than a successful one.
  • Looking for the smallest fix — after a list of clashing settings: checking for further conflicts, and for the fewest changes that would allow a timetable. Up to your plan's time limit once more (at least 30 seconds).
• COMPLETED — a schedule was found. If this wasn't a feasibility-only check, the result renders below as a Generated Preview, and a Save Timetable button appears in the header so you can persist it. It may say Completed with N warnings: the schedule is valid, but something in your data was ignored while making it, or the solver ran out of time to improve it. Read these before saving — see Warnings in When generation fails.
• INFEASIBLE — the solver ran successfully but proved no valid schedule exists for your current data. Common data mistakes (a class too big for every room, a lock on a break, a room tag no room has...) are caught before the search even starts, so this can come back within seconds. Each message has Edit links that open the records it names, ready to change, and an About this link to its entry in When generation fails, which explains how to read and fix each kind of problem. When the cause is a combination of settings, the result also suggests The smallest fix, and shows below a preview of the timetable that fix allows (it can't be saved: make the changes and generate again).
• TIMED OUT — the solver used its whole time limit (set by your plan; the result says how long) without either finding a schedule or proving none exists. Your data did pass the quick checks, so none of the common mistakes is to blame, but whether a schedule exists is still unknown — larger schools can simply need more time. Since a generation already looks for any valid schedule first, Check Feasibility rarely gets further in the same time; if it keeps happening, use Request Help so our team can raise your school's time limit. See When generation fails for what else to try.
• FAILED — something went wrong on our side (for example, the solver crashed). It isn't caused by your data. Try again; if it keeps failing, use Request Help and mention the request ID.

There's also a SUPERSEDED status you won't normally see: if you click Generate again while a previous request for your school is still waiting to be picked up (still PENDING), the older one is marked SUPERSEDED and skipped. This only applies to requests that haven't started yet, though — clicking Generate again while a request is already PROCESSING doesn't cancel it. The older solve keeps running in the background using up a worker slot, but its result is discarded: the page always shows whichever request was created most recently, so you'll only ever see the newest one's outcome. If you want to change something and re-solve, it's simplest to wait for the current run to finish (or fail) before queuing another.

Viewing the result

A completed, non-feasibility-only result renders as a Generated Preview using the same class/teacher/room filter described in Viewing by Class / Teacher / Room. This preview is read-only — it isn't editable here. To make manual adjustments, click Save Timetable first and continue from the saved-timetable editor.

Each new Save Timetable click creates a brand-new saved timetable row rather than overwriting one — see Manually editing a saved timetable for what happens after that, including how the saved editor's own re-solve flow differs from this page's.

Getting live help

If generation keeps failing and you can't see why, click Request Help at the top of this page. A platform admin is notified. Once they accept, they see a live, read-only view of what's on your screen, starting with this page's latest request and its explanation. As you move between the timetable screens (lessons, teachers, periods, and so on), their view follows yours. They can't change anything unless you grant them input access from the banner that appears at the top of the page. You can revoke that access or end the session at any time. If nobody accepts within 30 minutes, the request is withdrawn and you can ask again.