Skip to content

Squawk statuses

A squawk moves through a short lifecycle from first report to a terminal state. At any moment every squawk is in exactly one of five statuses.

dismissed ◀─ dismiss ── pending ── confirm ──▶ open ── resolve ──▶ resolved
│ ▲ ▲
defer │ │ deferral │ resolve
▼ │ expires │
deferred ───────────────┘

Terminal statuses: resolved and dismissed. A squawk cannot move out of these. A deferred squawk is not terminal: if its date passes before anyone resolves it, it returns to open and the asset is grounded again.

  • Members report squawks (creating a pending or open squawk depending on the syndicate policy).
  • Admins confirm, dismiss, defer, and resolve squawks.
  • Per-asset squawk list: /syndicates/:syndicateId/assets/:assetId/squawks.
  • Pending-approvals queue: /syndicates/:syndicateId/squawk-approvals.
  • Individual squawk detail: /squawks/:squawkId.
Status Serialised Terminal Counts toward “active”
Pending pending No Yes
Open open No Yes
Deferred deferred No Yes
Resolved resolved Yes No
Dismissed dismissed Yes No
  • Pending: reported by a member, awaiting admin review. Used when the syndicate setting “Require admin confirmation for squawks” is on and the reporter is not themselves an admin.
  • Open: active and in force. Grounding squawks in this state ground the asset.
  • Deferred: the admin has acknowledged the issue and allowed the asset to continue operating until a stated date, with a recorded reason. When the date passes the squawk returns to open and the asset is grounded again, unless it has been resolved first.
  • Resolved: fixed. No further action needed.
  • Dismissed: reviewed and judged not a real defect; dropped without a fix.
  • Starting status depends on syndicate policy and reporter role:
    • Confirmation required and reporter is not an admin → pending.
    • Otherwise → open.
  • Only pending squawks can be confirmed. Confirming transitions to open and stamps the confirming admin and time.
  • Only pending squawks can be dismissed through the approval flow. Dismissal requires a dismissal reason from the admin.
  • Only open grounding squawks can be deferred. Caution and info squawks have no ground effect and do not need deferral. Deferral requires a deferral date and a reason.
  • A deferral expires on its own. When the deferral date passes, the squawk returns to open, the asset is grounded again, and the members’ confirmed bookings that have not yet started suspend, unless an admin resolved it first. A flight already under way is left alone, so its usage stays loggable. See Airworthiness rules. The syndicate’s admins get a reminder on the day it expires.
  • Only open or deferred squawks can be resolved. A pending squawk must be confirmed first; a dismissed squawk is terminal.
  • Resolved and dismissed are terminal. Reopening is not supported. The correct response is a fresh squawk referencing the original.
  • “Active” squawks (pending, open, deferred) appear in the asset’s squawk list; terminal squawks are filtered out of the default view.
  • The pending badge on the approvals queue counts only pending squawks.

A daily sweep (each morning, 09:00 UTC) sends every admin of the syndicate a Squawk Needs Closing notification, linked to the squawk, in the two situations where a grounding squawk left unclosed quietly costs the group an aircraft:

Situation When the reminder fires
A deferred grounding squawk’s deferral date is today On the last valid day, so an admin can resolve the squawk (work done) or defer it afresh before the aircraft re-grounds the following day and its bookings suspend again.
An open grounding squawk’s linked repair booking ends today Nothing closes a squawk automatically when its maintenance booking finishes; the reminder prompts an admin to resolve it, return the aircraft to service, and reinstate any suspended bookings.

Only grounding squawks trigger the reminder, and each squawk fires at most once per day. The notification is push-on by default and can be turned off in notification preferences.