Reflections on 20 years of MyFlightbook

July 9, 2006.  That is the creation date of the oldest account on MyFlightbook, so I'll use that as MyFlightbook's "birthday".  Ironically, it's not even mine - I'm #30, somehow, more than a full year later (in November of 2007)!  At some point early on, I must have deleted and recreated my account, which means that MyFlightbook is actually a bit more than 20 years old now, but July 9 2006 is the best birth date I have.

I think 20 years on is a good time to take stock of things.

I had left a career at Microsoft and Expedia at the end of 2005, having spent 15 years as a program manager, group manager, and ultimately vice-president managing software development teams.  While very rewarding work, I had gotten very disconnected to the underlying technology, so I wanted a coding project.  I - like almost everyone then - used a paper logbook, and I found answering insurance company questions and filling out 8710 forms incredibly difficult.  Perfect - I had found my project.

From the start, I realized that I wanted this to be web based, unlike the then-standard of shrink-wrapped software for Windows or MacOS.  This would provide a number of obvious technical advantages such as access from anywhere, multi-platform support, and centralized logic that could be updated without new releases, but it would also enable new opportunities that the web enabled such as taking advantage of maps or images or even social media (Facebook had just started in 2004, and Twitter in 2006).

Home page screenshot, Jan 2007 courtesy of Archive.org; 

you can see that I once could design a killer Windows 3.0 user interface...

and clearly that's where I still remain!

Being ex-Microsoft, I chose IIS with ASP.NET and C# as my platform and started learning how to integrate MySQL for the database and how to configure a firewall for the server in my basement to allow for public access.  Yes, for the first several years, MyFlightbook ran out of my basement!  (Don't worry - I moved to a colocation facility, and then about 8 years ago moved fully into Google Cloud, so it has all of the modern data center hardware, redundancies, security, and monitoring that you'd expect).

Since then, the site has been (almost) completely rewritten (going from ASP.NET to MVC - I clearly like to stay on the cutting edge of whatever was hot 15 years prior!), I've added an iOS app (2009, in Objective-C that I rewrote in Swift a few years ago), and an Android app (2010 or so, originally in Java and since rewritten in Kotlin). 

Early on, I invited my pilot friends to give it a try and one of them created the aforementioned oldest account.  The user base grew slowly at first - I didn't spend anything on advertising (I think I once spent $100 on a Google ads trial, but didn't think it was worth it so never spent anything more), relying instead on word of mouth.  It took until 2010 before I hit 1,000 users.  I still rely entirely on word-of-mouth, and while I generally don't like to share super precise user counts publicly, as of this writing the number is comfortably into 6 figures with pilots from literally all over the world; all from pilot-to-pilot recommendations.  I don't have hard data about either the number of worldwide pilots (1.5-2 million, perhaps?  It's about 900K in the US), nor do I know how many MyFlightbook users hold certificates  of some level (I'd guess most), but I'm pretty confident that MyFlightbook accounts represent a double-digit percentage of the global pilot population.  A few months ago, I started using the tag line "The world's favorite free logbook", and I'm comfortable that assertion is true.

I came out of a GA background, which informed a lot of the design and original features, but the best ideas have always come from pilots who bring me scenarios I had never considered.  Today I suspect a majority of the users are GA pilots, but a majority of the flights being tracked are for airline pilots (which makes perfect intuitive sense - there are more GA pilots than airline pilots, but the latter fly a lot more frequently).  But I also have a good number of military pilots, balloonists, drone pilots, and even Microsoft Flight Simulator/X-Plane enthusiasts who use the platform.  This wouldn't be possible without people sharing their needs and use cases with me.  I love figuring out how to solve interesting challenges like these!

I've often been asked why I give MyFlightbook away instead of charging for it.  There have always been a few reasons why.  One is that if I charged for it, it would feel like a job, and I didn't want that - I'm insanely fortunate that I have other sources of income that give me time to devote to this, and I love that I can get into a coding frenzy for a week, and then go "dark" on new code for an arbitrarily long time.  Another is that I feel like flying is already expensive enough, and that everybody should have an electronic logbook; this shouldn't be one of those added expenses.  And finally, it was a way to give back to the community.  

However, in late 2013, I started accepting donations; I'm happy to report that I get more than enough in donations to cover out-of-pocket expenses such as hosting, domain and certificate registrations, and the like.  (I have never paid myself for my time, though; if I had done so, I'd have closed up shop years ago!)  More than the monetary value, donations provide a near-real-time indicator of the relevance and validity of MyFlightbook: $10 from somebody who owed me absolutely nothing is vastly more meaningful to me than $100 from somebody who formally purchased something from me.  The latter is just a business transaction; the former is a sign of appreciation; it is why I still enjoy doing MyFlightbook more than 20 years later!  

There have of course been a few hiccups over the years, the worst being when 9 years ago when I was still hosting on a physical machine at a co-location facility and I accidentally turned on the firewall for all traffic - including the incoming network connection I used to manage the machine itself, causing the site to be down for about 36 hours while I figured out a way back in. That was when I decided to move to Google Cloud; the good news is that no data was lost - I cut over to a backup server in my basement and migrated changes from that machine to the production server once the production server was available again.

But overall, it's actually been quite smooth, and typically the only downtime is the minute or so when I take out an update or when Windows Update needs to run.

MyFlightbook has grown considerably, in functionality as well as user base.  It is an open-source, community project, and while I've written the vast majority of the code, I have had invaluable help from others, who have contributed things like language translation, user interface designs/stylesheets/logos, and product support/monitoring.  I even wake up occasionally in the morning and discover that someone who wanted a feature wrote it themselves and submitted a "pull request" asking me to merge their code into the codebase!  And it has grown through partnerships with  complementary organizations/services as well, such as cloud storage, airline scheduling systems, debrief services, or even (in the most recent example) aircraft logbooks.

But the most important contributors to MyFlightbook are you, the pilots who use it.  100% of data about aircraft, models, and manufacturers comes from you, and your edits help not only make the database  of these what I suspect is the most complete on the Internet, you also help ensure that it is also the most accurate.  There are (as of this writing) nearly 375,000 registered aircraft in the system, representing nearly 7,000 models of aircraft, and which are used in over 26 million distinct flight entries.  You've even contributed over 4,400 airports/heliports/seaports that had otherwise escaped the attention of the FAA and other sources of such data.

So please join me in wishing MyFlightbook a happy 20th birthday, and lets look forward to another 20 years of logging the world's flights!

Bulk delete of a subset of flights

MyFlightbook has the ability to do a bulk-delete of flights (under Profile->Account->Big Red Buttons), but occasionally I am asked about bulk-deletion of a subset of flights (e.g., for a specific date range).  I don't have any tool for this that you don't have, so in this post I will describe how to do this.

These instructions work on the website only, not the iOS or Android apps, and it makes heavy use of the flights drop-down menu above and to the left of the list of flights, next to the count of entries.

Note that deletion is an irreversible operation; be sure to double check things at every step of the way.

1. I strongly recommend backing up your flights first (Logbook->Download).  Just in case...
2. Search for the set of flights that you want to delete.
3. If necessary, choose "Show All" from the flights drop-down menu:
   
   
   
   This will ensure that all of the matching flights are loaded for subsequent steps.
4. From the same menu, choose "Select Flights:"
   
   
   

   This will change the right-hand column of the flights list from flight-specific drop-down menus to selection checkboxes.
5. Above the column of checkboxes, click the "select all" checkbox:
   

   

   
   This will select all of the flights that, due to step one, meet the criteria for flights to delete.
6. Go back to the main flights drop-down menu.  It will have changed slightly because of the selected flights.  Choose "Delete selected flights:"
   

   

   
   
7. Repeat as necessary if you did not choose "Show All" in step 3.

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 class	6 calendar** months	12 calendar months	24 calendar months if you are over 40, otherwise 60 calendar months
2nd class	N/A
3rd class		N/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.

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.

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!