SolverForge
Search docs Ctrl K

Airline crew scheduling

10 flight legs. 24 crew. 42 required seats. Rotations that respect rest.

Crew scheduling fills every required cockpit and cabin seat while qualification, overlap, connection continuity, availability, and every rest and recovery window hold at the same time.

10 Flight legs
24 Crew
42 Required seats
12 Constraints
10 / 2 Hard / soft split
6 Airports

A valid rotation is more than a name in a seat. Every seat needs a qualified crew member, no two duties may overlap, connected flights must be operated in sequence, and each person has to be available. Rest is where it gets hard: home-base and away-base minimums, 36-hour extended recovery, and 48-hour recovery after long-haul duty all hold together.

Solve those rules one at a time and you get a roster that looks fine in one view and strands a crew member in another. The app keeps the crew timeline, the by-flight manifests, score analysis, the data tables, and the retained job in one model.

Seat coverage Every required cockpit and cabin seat is assigned.
Qualification Pilot and cabin seats require the matching skill.
Overlap prevention No crew member holds two duties that overlap in time.
Connection continuity Connected consecutive flights are operated in sequence.
Rest and recovery Home and away minimums, 36-hour extended recovery, and 48-hour long-haul recovery.
Soft preference The first departure and last return prefer each crew member's home base.
Runtime walkthrough Watch duty blocks land in the crew lanes, then confirm every leg seat by seat. Narrated walkthrough (2:04): the unassigned rotation, the solve in progress, crew rotations with unavailable-day overlays, the by-flight manifests, score analysis, the data view, and the REST surface.
Unassigned rotation The unassigned baseline states the problem plainly: 10 flights, 24 crew members, 42 required seats, none filled.
  1. Required seats and unassigned seats are stated before the solve.
  2. Crew lanes carry home base and role; no duty block exists yet.
Mid-solve Mid-solve, duty blocks are already appearing in the crew lanes while rest and recovery rules keep being checked.
  1. Duty blocks land in crew lanes as seats are assigned.
  2. The solver is live and the score is still improving.
Crew rotations The crew view is the rotation itself: duty blocks per employee with unavailable days overlaid, so rest is visible rather than inferred.
  1. Lane headers keep each crew member's role, home base, and flight count.
  2. Duty blocks sit against the day axis, with unavailable days overlaid.
Flight manifests The by-flight view turns the same plan around so operations can confirm each leg is covered seat by seat.
  1. Each row is one flight leg with its seat requirement.
  2. Seat blocks name the crew members assigned to that leg.
Score analysis Score analysis separates feasibility from quality: ten hard rules cover coverage, skill, overlap, connection, availability, and every rest window.
  1. Coverage, skill, overlap, connection, availability, and rest are hard rules.
  2. Home-base return stays visible as soft pressure on its own.
Data view The data view keeps the facts behind the rotation next to the plan: airports, employees with qualifications, flight legs, and the assignment table.
  1. Crew assignments expose which employee owns which required seat.
  2. Employees carry qualifications and home base as input facts.
REST API The REST surface exposes the retained-job workflow for integration: create a solve, read status, fetch snapshots, analyze, pause, resume, cancel, and stream events.
  1. Retained-job endpoints cover create, status, snapshot, and analysis.
  2. Lifecycle actions and the event stream are integration points as well.