Saturday, March 28, 2026

Expiration Dates for currency and FAA medicals

When you view your currency on MyFlightbook, you often see an expiration date next to a currency.  The dirty little secret here, though, is that it's a fiction.  Most currency doesn't technically ever expire.  It's something you have or you don't have, and it's generally backwards-looking.  (The discussion below is entirely in the FAA context, but it largely applies as well under other regulatory environments).

Generally, when I compute a currency, I'm asking 2 questions:

  • Can you exercise the privileges that require this currency today, and
  • What is the last day that you can exercise those privileges based on what is in this logbook as it is right now.

A simple example is to imagine that you did 1 takeoff/landing* on Jan 1, another on Feb 1, and a third on March 1.  As I write this, it is March 28, 90 days ago is December 28 2025.  So if I look back 90 days, I will see all three takeoff/landing pairs, and thus you are current per 61.57(a).  Now I ask "what is the last day when that will be true" and the answer is April 1, because on April 1, the preceding 90 days will include all three flights, but on April 2 the preceding 90 days only goes back to Jan 2 and thus only encompasses the latter two flights.  So your "expiration" date is April 1.  

Does that mean that your currency expires on April 1?  No - if you do two more takeoffs/landings on March 29, then you will be current until June 27, assuming no more flying.  So the "expiration" date continuously moves based on your flying; it's not something that exists on its own.

I realize that this can be an esoteric distinction, but it is a source of confusion, particularly because currencies can have multiple such "expiration" dates!  

A great example here is instrument currency (61.57(c)).  You can be current by virtue of doing the 6 approaches/holding in 6 months, or you can be current by virtue of having had an IPC.  These can each "expire" on different dates!  Indeed, I get questions from pilots who click on a currency to see the flights that contributed towards its computation and don't see the flights they expect to see, and it is often because they are thinking of one path but the one MyFlightbook used was from another path.  MyFlightbook computes all of the paths and reports as the expiration date whichever is the latest; in the event of a tie, one path is picked arbitrarily.  A question I received just last week was from a pilot who thought his simulator sessions weren't counting because when he clicked on his instrument currency, it showed him his instrument checkride rather than the flights with approaches/holding.  In his case, both paths yielded the same date, and the system picked the checkride.

Another example is 61.57(e), which is a complicated alternative to 61.57(b) pilots to remain night current for some turbine operations.  I won't go into the details of 61.57(e), but it can extend night currency for up to 12 months, but MyFlightbook never shows a 12 month expiration because a constituent piece is that you must be current by 61.57(a) as well, and that's 90-day limited.  I've had pilots be confused because there are multiple paths to currency (61.57(b) and 61.57(e)) that yield different expiration dates, and they're expecting one that is different from what MyFlightbook reports.

All of the currencies above are experience based, so the "expiration" date moves with experience, but the principle here holds even for date-based currency, such as your medical certificate.

Technically, your medical doesn't expire, even though MyFlightbook reports an expiration date for it.  Rather, you can think of the privileges it bestows as decaying over time.  Just yesterday, I had a pilot tell me that MyFlightbook's computation was incorrect because he got a 2nd-class medical and those, he said, last for 24 months for someone over 40.

He's correct in one sense, that you cannot exercise privileges requiring a medical without seeing a doctor after 24 months.  But I think he missed the larger point that nobody cares about the certificate per se.  Pilots need to care about the privileges that the certificate allows you to exercise.  

The duration of a medical is described in 61.23(d), in what I think may be the most obtuse possible way.

I would, instead, summarize that duration table this way, which is I hope far simpler and more clear than the FAA's formulation:

Class of medical 1st class privileges expire 2nd class privileges expire 3rd class privileges expire
1st class6 calendar** months12 calendar months24 calendar months if you are over 40, otherwise 60 calendar months
2nd classN/A
3rd classN/A

So the pilot above has a 2nd class medical that is good for 12 months for operations requiring a 2nd class medical, and its good for 24 months for operations requiring a 3rd class medical.  In other words, it's not the certificate per se that has an expiration date, it's the privileges it confers - and there are multiple such privileges simultaneously!

MyFlightbook handles these multiple privileges automatically.

For example, I am over 40 years old.  If I put in a 2nd class medical using November 2025 (it's March of 2026 right now), then I'll see this in my currency:


This is the 12-calendar month expiration that the pilot referred to as being in error.

But if I change the date of that 2nd-class medical to Nov of 2024 instead of 2025, the "expiration date" bifurcates:

Still a 2nd class certificate, but MyFlightbook is now reporting that the 2nd class privileges expired at the end of Nov 2025 (12 calendar months from the date of the exam), but that 2nd class certificate is still valid for operations that require only a 3rd class medical until Nov of 2026! 

Hopefully this clarifies how "expiration dates" work in MyFlightbook.


*61.57(a) requires both takeoffs and landings, but MyFlightbook ignores takeoffs for this computation because they are so rarely logged as a practical matter.  Night currency is more strict about this - it ignores them if it finds none and warns you that you need to do them, but if even one night takeoff is logged anywhere in your logbook, they become required.

**Interestingly, while the FAA is usually really good about using the phrase "Calendar Month" when they mean calendar month, in the table of 61.23(d), they use the phrase "...at the end of the last day of the (Nth) month after the date of the examination on the medical certificate."  This is functionally the same, just expressed in a more verbose manner.

Wednesday, January 21, 2026

What airlines look for in a logbook

Last week I had the honor of being invited to a meeting between American Airlines' Pilot Hiring Team and providers of pilot services such as logbooks (myself, obviously), interview preparation, military to civilian conversion, etc.  We got an overview of their hiring philosophy, but (to my pleasure) spent most of the time discussing logbooks.  With their permission, I am summarizing here my key takeaways and how you can use MyFlightbook to put your best foot forward.  Obviously, this is one airline, but I'd be very surprised if the advice and guidelines here don't carry across to any other airline.

I'll quickly cover the high level items; none of these should be a surprise.  They want to see  that you:

  • Are professional
  • Communicate well
  • Are detail oriented
  • Produce everything that they request
  • Provide consistent, accurate and transparent data (more on this below, since this speaks to logbooks)
  • Have original documents (not copies) of your certificate, medical, passport, etc.
  • Handle stress well
  • Dress appropriately
  • Overall show that you would be a good representative for the airline.
There are multiple touch points between an airline and an applicant before an interview, and they are paying attention to these attributes at every one of them.

OK, let's talk about your data.  I heard a few key themes.

The first is that they want to see that you adhere to proper logging standards, specifically 61.51.  Some of the common issues with this include:

  • Missing tail numbers
  • Logging sim time as total time.  If it's not in an actual aircraft, leave total time (and PIC and SIC) blank.  I've addressed this in the blog before, and I recommend using the Check Flights tool to help you find flights where you may have done this.  Yes, some sim time can contribute towards the required total flight time for some certificates, but that's a credit, not total time.  (I.e., if you need 1000 hours for something and the regs let you apply 50 hours of appropriate sim time towards that requirement, you don't get to log 50 of those appropriate sim time as total time.  What they're saying is that "the sum of your aircraft time plus MIN(50, appropriate sim time) must be at least 1000hours")
  • Doing a single entry for all of the flights in a month or a week flights is not acceptable . However, aggregating multiple flights on a single day is fine as long as the city pairs and ship/N numbers are logged.  If you converted from paper logbooks to electronic, and have a few catch-up flights to make the totals continuous (as the starting totals tool will do for you), that's fine - but they want to see the original paper logbooks that are the source of those catch-up flights.
  • Logging deadhead time as total time.  Or "Bunk time".  E.g., if you are in a multi-person crew on a 10 hour flight that typically requires 3 pilots, they want to see 6.7hours (not 10); on a 12 hour flight with 4 pilots, you should be logging 6 hours.  More to the point: don't log it if you're not seated at the controls, even if giving instruction from the jumpseat.
  • They didn't specifically mention these two 61.51 requirements, but I will because I see it all the time (and again, the Check Flights tool can help with this):
    • If you log time in a sim, you are supposed to log the details of that sim session.  Things like the location, the serial # or registration of the sim, and so forth.  In MyFlightbook, whenever you choose a sim as an entry's aircraft, it will automatically show a "Simulator/Training Device Identifier" field to contain this information; the field auto-completes to previously used values for ease of data entry when re-using a sim.
    • If you log approaches, you're supposed to log the details (type, location) of the approach.  Both the website and the iOS/Android apps have an "approach helper" (use the "+" button next to the approach count) that helps you to capture this data.
There was a bunch of discussion around military pilots, much of which I didn't follow (being a civilian pilot myself), but a few items that I did note:
  • "Military Other Time" is often very vague and contains a lot of time that they don't count (for example, where you weren't actually the one manipulating the controls).  Best to use other more specific fields.
  • Military sorties are typically logged wheels-up to wheels-down, and it's standard to add 0.3hrs when converting this to civilian time, but they find it helpful if this time is broken out.  I don't have a formal way to do this at the moment; one way to do it might be that if you have 100 military flights, put one more flight with 100 x 0.3 = 30 hours to denote the extra .3 hours and make it clear the function of that entry; or, perhaps this would be a good use of the "Military other time" - put 0.3 into that field for each such flight.
  • Airlines fly airplanes, not helicopters, so they really want to focus on the airplanes.  MyFlightbook by default does break out category/class totals at the top, so helicopter time vs. MEL Airplane vs. SEL airplane make this pretty easy.
  • Unmanned time doesn't count at all for the experience they're looking for; don't include it in your total time.
  • If you use the ARTEMIS system, it produces an Excel spreadsheet.  Bring that as-is; don't personalize it.
Anyhow, I will put in a strong plug here again for using the Check Flights tool to ensure that you are following best practices in logging of your time; it has over 150 different checks, and will highlight all sorts of potential issues.

The second big theme I heard was around consistency, honesty and transparency.  If you busted a checkride, don't hide it.  Own it, be able to speak to what you learned from it.  They will find out, and if you tried to hide it, game over.  They've had candidates who filled out their application and said one number of hours, but the logbook showed a different number of hours.  They do allow a bit of slop in this (about 10% - which is more than I would have expected!) but the numbers do more or less need to tie.  If there is a significant gap, that raises all sorts of questions that you don't want to have to answer.

If you lose your logbook or it is stolen (a good argument for an electronic logbook!), you need something that counts as original.  Best to submit Form AC 8060-68 (Request for Copies of My Complete or Partial Airman File) to get a copy of the FAA's official records.

The third theme I heard was around presentation.  At American, at least, they get about 40 applicants a day and they have only 3-4 people reviewing logbooks, so the easier you can make it for them, the better.  I've given talks at OSH about this topic and have posted about it as well.  You do not need to get fancy for the sake of being fancy, but you do want to make their life as easy as possible.  Some additional tips for presentation:
  • They want to be able to find checkrides and re-checks easily.  Use sticky tabs for this (if using paper), and/or flight coloring to make important flights like these stand out.
  • They want to see your original paper logbooks, coffee stains and scratch-outs and all; don't try to make them what they aren't.  And even if you've transcribed them into MyFlightbook, if it was originally entered on paper, then the paper is the legal original and they want it.
  • If it's paper, make sure every page is wet-ink signed.  You need to formally stand behind your data.  Note that in MyFlightbook, if you print to paper, you can print incrementally using the "Resume from last printout" option on the "What to include" tab of the printing page so that you only have to sign new pages as they are created.  MyFlightbook now also supports digital attestations of a PDF version of your logbook, which follows the guidance in AC-120-78B and thus should be acceptable to the airlines.
  • It's a good idea to write up a cover page telling them where to look to find important data, particularly if your logbook is spread across multiple media.
  • Bonus points for adding Turbine/SIC and Turbine/PIC times.  These are available as optional columns you can add to most of the print layouts.
  • If you have questions, reach out with them. Don’t wait until you arrive for your interview to ask. 
The good news if you use MyFlightbook is that it has all sorts of tools to help ensure that you are logging correctly and displaying it appropriately. 

I found it very helpful to hear all of this from the source; I hope these tips are useful for you as well.

Sunday, January 18, 2026

Digitally signed PDF of your logbook

You've long been able to download a PDF that you can print and laboriously sign each page. (And a few months ago I added functionality that let you print incrementally, saving a bunch of work.)

But saving trees and avoiding hand cramps/carpal tunnel syndrome was hard because many people wouldn't accept a PDF file as having your attestation (even if you're the one giving it to them, which is kinda dumb, but hey...)


ANYHOW, on the PDF download screen, there is now an option to digitally attest to the accuracy/authenticity of the logbook PDF. It will collect a digital scribble from you (the primary point of which is not to have an ink-like scribble per se, but rather to meet AC-120-78B's requirements for intentionality and non-refutability), and instead of downloading a PDF, you'll download a zip file with 2 PDFs inside.

The first of those is the regular PDF you've always known and loved, but instead of "Signed by [your name]________" in the footer, it instead says "Signed by [your name][See accompanying attestation for validity notes]".

The second PDF is a digital attestation for the validity of the first PDF, and it includes your scribble and, importantly, the "SHA256" hash of that PDF. That's the cryptographic signature of the file that proves it's the one you signed. It also includes instructions for the recipient that they can use if they want to verify that the PDF file you sent them is the one that you digitally affirmed is true and correct and yours. Even the most minor edit or change to the PDF will change the hash, and if the hash values don't agree, then the attestation fails.

So you can send the two PDFs to a potential employer or insurance company or anyone else who requests your logbook, and they should (at least per AC-120-78B) accept it.

Hopefully this will result in less actual paper - and less strained wrists!