A roster period is the block of time a business treats as a single planning unit when publishing and allocating shifts — for example a week, a weekend, or a full seasonal run of event nights.

How it works

A roster period typically contains a number of individual shift days or nights, each with its own work published inside it. The period as a whole moves through a lifecycle: it's built (the available work laid out), opened for bidding, allocated once bids close, confirmed, run, and finally completed. Completion is often the trigger for period-level calculations, such as recomputing a reliability score across everyone who worked it.

The length of a roster period is usually configurable to match how the business actually operates — a retailer might roster weekly, while a weekend-anchored venue might treat each Friday–Sunday block as its own period, and a seasonal business might run one long period spanning an entire event season.

Why it matters

Defining a clear period boundary matters because it's the unit everything else hangs off: bidding windows, allocation decisions, and reliability scoring are all evaluated per period, not continuously. A period that's too short creates constant admin overhead; one that's too long makes it harder to react to changing demand or availability.

In Chronomancer

A period in Chronomancer is a configurable window containing a set of nights (specific event-days — weekends, specials, public holidays). Each period runs through the full roster state machine — Draft, Bidding, Allocating, Scheduled, Live, Completed — and reliability scores recompute automatically when a period is marked Completed.