The gap between knowing and doing
Most pilots who fly IFR regularly can recite the fact that navigation databases run on a 28-day AIRAC cycle. Far fewer have a routine that reliably keeps every database in their aircraft current against that cycle, particularly once more than one piece of equipment, and more than one provider, is involved. The gap between knowing the rule and having a system that enforces it is where most expired-database incidents actually come from.
Step one: know exactly what needs updating
Before a routine can work, it needs a complete list. For a single-navigator aircraft this is straightforward. For an aircraft with a mix of Garmin, Jeppesen-format and Honeywell/Bendix King equipment, or a pilot who also carries a portable navigator or runs Garmin Pilot on a tablet, the list is longer than it first appears: a panel-mount GPS, a portable backup unit, an EFB app, and potentially a separate multi-function display, can each be running a database from a different provider on its own subscription.
Step two: renew ahead of the flight, not in response to it
A subscription that renews automatically removes one point of failure; a subscription that requires manual renewal each cycle should be tied to a fixed reminder rather than to memory. Because the cycle is exactly 28 days, a recurring calendar reminder set to that interval, rather than a monthly reminder that slowly drifts out of alignment with the actual AIRAC dates, keeps the renewal and the cycle in step.
Step three: actually load the update before flying
Renewing a subscription and loading the resulting data onto the device are two separate steps, and the second is the one that is more easily skipped under time pressure. A database downloaded to a laptop the night before a flight but never transferred to the navigator or panel unit provides no benefit at all. Build the load step into a fixed point in preflight preparation, not into whatever time happens to be left over.
Step four: verify the effective dates, not just that an update ran
Most avionics and EFB apps display the current database's effective date range on request. Checking that figure against today's date, rather than simply trusting that an update process completed without error, catches the case where an update silently failed, was interrupted, or loaded the wrong region's data for a provider offering region-specific subscriptions.
Common failure points worth watching for
- Treating a subscription renewal as the same thing as an updated database, when the data still has to be downloaded and loaded onto each device separately.
- Updating only the primary panel navigator while a portable backup unit or EFB tablet quietly runs on an older cycle.
- Assuming a Jeppesen Database Update subscription covers Honeywell/Bendix King avionics, when that equipment is supplied through its own Wingman Services distribution channel even though the underlying data source is the same.
- Losing track of renewal dates across a fleet with mixed avionics, where different aircraft may be on different providers and different renewal schedules.
- Discovering an expired database during preflight immediately before a flight that depends on it, rather than catching it with enough lead time to update before departure.
Making it a system, not a habit
The pilots who never fly on an expired database are rarely the ones with the best memory. They are the ones who have turned the 28-day cycle into a fixed, recurring task rather than something to remember. ASPL supplies and renews Garmin, Jeppesen and Honeywell/Bendix King database subscriptions for operators and fleets in India, and can help set up a renewal schedule across mixed-avionics aircraft so currency is tracked centrally rather than per pilot.