# F5 service check date > Enter a BIG-IP version to get the minimum service check date its license must carry, or enter a service check date to see the newest version you can upgrade to. Based on F5's published License Check Date table (K7727); runs entirely in your browser. - Tool: https://ronutz.com/en/tools/f5-service-check-date - Family: Networking --- ## What it does Give the tool a BIG-IP version and it returns the minimum service check date that version's license must carry; give it a service check date and it returns the newest version you can upgrade to, along with the newer branches you cannot reach yet and the date each one needs. It is a two-way lookup over a vendored copy of F5's published License Check Date table, and it runs entirely in your browser. ## The two dates it works from Every BIG-IP version carries a static **License Check Date**: the minimum service check date a license must have to be allowed to boot that version. Every license carries a **Service Check Date**: the earlier of the date it was last activated and the date its service contract expires. When you upgrade to a new major or minor version, the system compares the two, and if the license's Service Check Date is earlier than the version's License Check Date, the upgraded system boots but does not load its configuration until the license is reactivated. The tool encodes F5's License Check Date table (from K7727) and does that comparison for you, in either direction. Dates are handled in the exact form BIG-IP writes into `bigip.license`, the eight-digit `yyyymmdd` (so `20230208` is 8 February 2023), and shown in ISO form too. The comparison is pure date arithmetic with no clock involved: both the version's date and the service check date are inputs, so the same inputs always give the same answer. ## Worked examples Enter a version, get its floor. `17.1.3` resolves to the `17.1.x` branch and reports a minimum service check date of `2023-02-08` (`20230208`); `21.1` reports `2026-04-15`; `16.1.x` reports `2021-06-11`. Enter a service check date, get your ceiling. A service check date of `2023-06-15` reaches up to `17.1.x` as the newest branch, and reports the branches you cannot reach yet: `17.5.x` (needs `2025-02-12`), `21.0.x` (needs `2025-10-29`), and `21.1.x` (needs `2026-04-15`). A recent date such as `2026-05-01` reaches the newest branch with nothing blocked; a date older than the whole table reaches nothing, the signal that the license needs reactivating before any upgrade. ## Only major and minor upgrades are gated The check applies to an upgrade, which F5 defines as a change in the first or second version number. A move between maintenance or point releases within the same branch is an update, and it triggers no service check date verification at all. That is why the tool works at major.minor granularity: once your service check date is recent enough to reach `17.1.x`, it is recent enough for every maintenance and point release in that branch. So the answer for `17.1.0`, `17.1.3`, and `17.1.x` is the same single date. ## Using it Type a BIG-IP version (`17.1.3`, `21.1`, `16.1.x`) or a service check date (`20230611`, `2023-06-11`, or `2023/06/11`); the tool detects which you gave and answers accordingly. Because this encodes vendor documentation rather than a fixed standard, and F5 adds a row with each release, confirm any value against F5 K7727 or the target system's `/etc/version_date` before a production upgrade. ## Pasting a license or tmsh output You can paste the entire contents of `/config/bigip.license`, any fragment of it, or the output of `tmsh show sys license`; the tool finds the service-check-date line and answers the same upgrade-eligibility question. Both published line forms are recognized: the file form `Service check date : 20151008` (flexible spacing around the colon) and the tmsh form `Service Check Date 2016/08/18`. A license carries exactly one such line, so the first match wins, and the matched line is echoed back so you can confirm the right value was picked up. Everything else in the paste is ignored and, as always, nothing leaves your browser. ## Standards and references - [F5 K7727 - License activation may be required before a software upgrade for BIG-IP](https://my.f5.com/manage/s/article/K7727) - the per-version License Check Date table, the Service Check Date definition (earlier of last activation / contract expiry), and the enforcement behaviour on upgrade and startup - [F5 K8986 - F5 product support policies](https://my.f5.com/manage/s/article/K8986) - BIG-IP version schema: the major / minor / maintenance / point-release definitions that fix the upgrade-vs-update boundary the gate applies to - [F5 K3782 - Finding the serial number or registration key of your BIG-IP system](https://my.f5.com/manage/s/article/K3782) - the tmsh 'show sys license' field set and sample line forms (Service Check Date in yyyy/mm/dd form) that the paste extractor accepts - [F5 K000160443 - Understanding the output of tmsh show sys license on BIG-IP](https://my.f5.com/manage/s/article/K000160443) - field-by-field meaning of the license output (Licensed On vs Service Check Date vs License End Date) and confirmation the license file lives at /config/bigip.license ## Related reading - [Anatomy of a BIG-IP License File](https://ronutz.com/en/learn/bigip-license-file-anatomy.md): The /config/bigip.license file is human-readable, and learning to read it answers real operational questions: which modules are actually licensed, what the throughput and session limits are, whether an upgrade will load, and whether BIG-IQ is managing the license. Here is the file, section by section, from two real lab licenses. - [BIG-IP Upgrade vs Update: Why the Distinction Decides Whether the License Date Is Checked](https://ronutz.com/en/learn/bigip-upgrade-vs-update.md): F5 draws a precise line between an upgrade and an update, based on which part of the version number changes. It is not just terminology: the service check date is only enforced on an upgrade, so knowing which one you are doing tells you whether a licensing date can block you. - [BIG-IP, TMOS, and F5OS: A Version Timeline You Can Slide Through](https://ronutz.com/en/learn/bigip-tmos-version-timeline.md): BIG-IP the platform and TMOS the software were the same thing until 2004, when version 9.0 split them and moved the box from BSD to a Linux host with the TMM microkernel. This interactive timeline slides from the 1997 BIG-IP Controller to BIG-IP 21.0, showing the software version and the operating system underneath it at each step, including why the numbers jump straight from 17 to 21. - [Recovering a BIG-IP That Won't Load Its Config After an Upgrade](https://ronutz.com/en/learn/bigip-license-reactivation.md): When an upgraded BIG-IP boots but its configuration never loads, the usual cause is a service check date older than the new version requires. The fix is to reactivate the license, which resets the date. Here is how to recognize it, how to reactivate safely, and how to avoid it next time. - [The BIG-IP Service Check Date, and Why an Upgrade Can Refuse to Load](https://ronutz.com/en/learn/bigip-service-check-date.md): Every BIG-IP version carries a static License Check Date, and every license carries a Service Check Date. If the license's date is older than the version's date, the upgraded system boots but silently refuses to load its configuration. Here is what each date is, where it comes from, and how the check works.