How to read the run report#

For: Manager You’ll need: A finished run — see How to assign people automatically.

The run page is the whole record of what a run did and what it couldn’t do. Read it before you publish. Every shift and person in it links straight to its edit page, so you can fix something and come back.

The range line#

At the top, one line names the dates the run covered and how far it reached into published shifts — for example “Filling unpublished shifts from … to …. Published shifts are not changed.”

The summary line#

Right below it: how many assignments were added, how many were removed, and how many errors and warnings the resulting schedule carries. When the run was started with ‘Keep the usual crew’, a count of assignments kept consistent with the previous period appears too.

Errors are the ones that matter. A plan you can publish with a clear conscience shows 0 errors.

Changes employees can already see#

This warning block appears only when the run touched a published shift. Those changes have already gone out — removal notices to anyone taken off, and to anyone added either an acceptance request (if your company requires shift acceptance and the shift hasn’t started) or a notice that they were added. Everything else in the report is still a draft nobody has seen.

What changed#

One row per assignment the run wrote: the shift, the person, and whether they were Added or Removed. A Live badge means that row is one of the changes employees can already see.

Any validation issue sits directly underneath the row it belongs to, marked with an error, warning, or info icon — so a problem is next to the change that caused it rather than in a list at the bottom of the page.

Still below target#

Shifts the run staffed partially — some people are on them, but fewer than they need. Each row shows how many heads short it is, plus the reason. A shift that’s short of its minimum shows up here as an error.

Unstaffed shifts#

Shifts that stayed completely empty, whatever headcount is configured on the position. Shiftavo assumes every shift wants at least one person, so an empty shift is always worth telling you about.

The reason column tells you why each stayed empty. See Why a shift stayed empty.

When a run can’t deliver#

A shift that can’t reach its minimum doesn’t stop the run — the report lists it under Still below target, or under Unstaffed shifts if nobody could be placed on it. A run that couldn’t complete at all ends in the ‘Failed’ state instead of producing a report, with the reason underneath and a ‘Back to planning’ button that returns you to the calendar. Reasons you may see:

  • “There are no shifts to fill in this range.” — nothing in the range was open to the run. See What automatic assignment respects.

  • “The time limit ran out before a valid assignment was found. Narrow the range, then generate again.”

  • “Scheduling rules or employee eligibility changed during this run. Generate again to use the current settings.” — the run fails before saving assignments or notifying people. Changes to contact details do not stop a run.

  • “This run stopped before completing. Start a new run.” — the run was still waiting or working an hour later, so it was marked failed.

Before it saves anything, a run checks that it is still running. One that was marked failed in the meantime saves nothing and notifies nobody, even if the solver finishes later; its page then reads “This run is no longer running.”

Tip

The report is a snapshot of what this run did — it doesn’t update as you keep editing the calendar. That’s deliberate: it stays an accurate record of the run.

Gap counts use the assignments that remain after the run saves its changes. A shift that the run could not change is excluded from these gaps.

Verify it worked#

Click a shift in any table. It opens that shift, and the people the run proposed are on it as draft assignments.