EOL Radar is a free weekly email that lists everything going out of support in the next 90 days and gives you a ready-made ServiceNow query for each entry, so you can see what your configuration management database (CMDB) says about end-of-support software in seconds. It also rounds up the critical vulnerabilities that made the news in the past seven days, and when a serious one breaks mid-week, we aim to send the matching query as it is announced. You can subscribe here. This article explains what is in each issue, how to run the queries if you have never built a ServiceNow filter, and what to do with the results.
Key Takeaways
- EOL Radar is a free weekly email listing everything that leaves support in the next 90 days, with a ready-made ServiceNow query for every entry.
- Each query is pasted after your instance address and opens a read-only, filtered list of configuration items; no filter building or query language is needed.
- Every issue rounds up the week's critical vulnerabilities, and breaking alerts are sent as serious vulnerabilities are announced rather than waiting for the next issue.
- A query result is a claim to verify: zero results can mean a discovery gap, and long lists mix live exposure with records nobody retired.
- End-of-life software receives no security fix at any severity, which is why end-of-support dates belong on the same radar as vulnerabilities.
What lands in your inbox each week
The problem EOL Radar solves is a quiet one. End-of-support dates are published years in advance, yet they still arrive as surprises, usually in the middle of a vulnerability review when someone asks whether the estate is exposed and expects an answer within the hour. The information was always available. Nobody had assembled it, pointed it at the CMDB, and put it in front of the right person a quarter ahead of the deadline. If you are newer to what a CMDB is there to do, that context helps explain why the queries work the way they do.
Each issue covers a rolling 90-day window and has the same shape, so a regular reader can go straight to what matters:
- The headline entries. The three to six biggest deadlines in the window, chosen by install base and nearness. Windows Server 2016 ending on 12 January is a current example. Each one carries context on what ends, what continues and where the trap is, plus its query.
- Now out of support. What crossed the line since the last issue. The queries for these entries have changed meaning: a week earlier they showed upcoming work, now anything they return is running without security updates.
- A date moved. Vendors shift lifecycle dates in both directions. When Zabbix pushed 7.4's end date from December to March, subscribers could take it off this quarter's plan. Reprieves matter as much as deadlines.
- The full table. Everything else in the window, with the CMDB table to look in for each product.
- The combined queries. One query per table family, chaining every entry in the issue, for readers who want one list per table instead of twenty.
- In the news. The critical vulnerabilities of the past seven days that a CMDB owner will be asked about, each with the query that shows where the affected product runs.
Every date is compiled from vendor lifecycle data, and the headline entries are checked against the vendor's own pages before an issue goes out. We still print the same caution every week: confirm against the vendor page before a change advisory board takes a decision on it.
How to run the queries without knowing ServiceNow's query language
Each query is a filter written as a web address path. You do not build anything in the interface.
- Open ServiceNow as you normally would and copy your instance address from the browser, up to and including .com.
- Copy the query from the issue, exactly as written. Spaces are fine.
- In the address bar, join them: your instance address, a forward slash, then the query. Press Enter.
- You are looking at a standard list of configuration items (CIs) with the filter already applied. The breadcrumb at the top shows the conditions; click any part of it to adjust them. Right-click a column heading and choose Export if you want it in a spreadsheet.
Opening a list changes nothing in your instance; it is read-only. If you get a security-constraints error instead of a list, your account cannot read that table, and the practical fix is forwarding the issue to whoever owns your CMDB.
One honest caveat: field values vary between instances. Status codes and version formats depend on how discovery and normalisation were configured, so if a query matches the wrong things, the breadcrumb shows exactly what it filtered on and where to adjust.
Zero results, long lists and the servers with no record at all
A CMDB query answers one question only: what does the CMDB currently believe? Every issue repeats this, because the number on the screen is a claim to verify rather than a fact, and it can be wrong in three directions at once.
Zero results means the product is gone from the estate, or discovery never reached the corner where it runs, or normalisation mangled the version strings the query matches on. A long list mixes real exposure with CIs for servers decommissioned years ago that nobody retired, and software that was uninstalled while its record lived on. And no query can return the machines that have no CI at all, which run the unsupported software too.
This is why each issue tells you to verify before the number reaches anyone senior. A migration plan sized against unretired records fails twice, once in the budget and once in the delivery. The newsletter's job is to get you to the right list quickly; whether that list reflects the estate is a function of your discovery coverage, reconciliation and retirement discipline. The consequences of getting that wrong show up in patching first, as we covered in how bad CMDB data produces false patch compliance.
Breaking vulnerabilities do not wait for Sunday
End-of-support dates are predictable. Exploited vulnerabilities are not, and the useful window for "where does this product run in our estate?" is the first day, not the following week.
So alongside the weekly issue, subscribers get occasional breaking alerts: when a vulnerability is critical, confirmed exploited in the wild, and relevant to enterprise estates, we aim to send the where-does-it-run query as the news lands. The bar is deliberately high. An alert channel that fires every day trains people to ignore it, so quiet weeks are quiet.
The October PHP vulnerabilities known as php2shell show why this belongs in an end-of-life newsletter at all. Fixes shipped for supported PHP versions within a day. PHP 7.3 and earlier received nothing, because end-of-life software gets no fix at any severity. An end-of-support date is a vulnerability announcement with years of notice.
What the weekly habit buys you
Readers tell us the queries save an afternoon per issue, and that is the shallow benefit. The deeper one is that a 90-day view changes when the work happens. Windows Server 2016 reaching end of support in January is a budget conversation in October and an emergency in February. A change freeze in December eats a month of the runway, and the issue says so while there is still time to act.
There is also a defensive benefit. When the audit, the insurer's questionnaire or the post-incident review asks how the organisation tracks unsupported software, "a weekly review of end-of-support exposure against the CMDB, with findings verified before action" is a process. Most organisations cannot name one.
How Apex helps
If the queries keep returning lists you cannot trust, that is measurable, and it is what we do. Apex's discovery and integration coverage review establishes what is missing from your estate view, where, and what it costs you during an incident. Our data quality assessment identifies where de-duplication, normalisation and reconciliation are failing and why. And the two-week CMDB health baseline scores which of your CIs are trustworthy and which are guesses, as a report you can take to a change advisory board.
Subscribe to EOL Radar to get the weekly report, or book a CMDB diagnostic call if this week's queries already found something you did not expect.
Frequently Asked Questions
Is EOL Radar free?
Yes. It is a weekly email with no paid tier. The queries, the instructions and the breaking alerts are all included, and you can unsubscribe at any time.
Do the queries change anything in my ServiceNow instance?
No. Each query opens a filtered, read-only list of configuration items. Nothing is created, updated or deleted, and you can share the same address with a colleague, who will need their own login and read access to the table.
What if we don't have Software Asset Management?
Software entries use the Software Asset Management install table where populated, and each issue gives an application-CI fallback query. If neither returns anything for software you know you run, that result is itself a finding about your discovery coverage.
Where do the dates come from?
From vendor lifecycle pages, compiled via the endoflife.date dataset and checked against the vendor's own page for every headline entry. We still recommend confirming against the vendor page before a change advisory board acts on a date.
What counts as a breaking alert?
Critical severity or confirmed exploitation in the wild, in software that runs in enterprise estates, verified against the vendor advisory. Anything below that bar waits for the weekly round-up, because an alert channel only works if it is quiet by default.
Written by Krzysztof Chrzanowski, Apex Configuration Group.
Book a free call to discuss how Apex can help you on your journey to a better CMDB
