ESO Addons "Out of Date" After an Update — What Actually Broke (and What Didn't)

What this page was checked against

Built 2026-08-22. Checked against the live game as it stood that day: interface (API) version 101050, which is Update 50, live since 2026-06-08. The next interface bump, Update 51, goes live on PC/Mac on September 28, 2026. Every rule quoted below carries the date it was fetched — all of the ESOUI quotes on this page were fetched on 2026-08-22, and the Update 51 date was verified at the ZeniMax announcement on 2026-08-19 and not re-fetched since.

You can read your own client's number in-game. The ESOUI dependency sticky gives the command verbatim: "/script d(GetAPIVersion())" (esoui.com/forums/showthread.php?t=9149, fetched 2026-08-22). If that prints 101050 you are on the same build this page was written against.

What the game actually checks: one line

It is a number comparison against one directive in the addon's manifest. ESOUI's out-of-date sticky, fetched 2026-08-22, verbatim: "Only one line is used to check if 101031 is present in the mods text file." (The 101031 in that sentence is that post's own 2021 example; the live value is 101050.) The same page, verbatim: "When the line with APIVersion does not contain the same value as the current API then you will see a notification of "Out of Date" on the same line as the name of the mod in the UI." And the dependency sticky puts it in one clause, verbatim: "It’s just a comparison of a value stored in the txt file of the addon/library to the currently internal in-game APIVersion (number comparison)."

So the flag is produced by the addon's ## APIVersion line and nothing else. Not by its code, not by whether it works, not by how old it is. Two real manifests, read from our addon corpus 2026-08-22: Pithka's Achievement Tracker declares "## APIVersion: 101046". SkyShards declares "## APIVersion: 101047 101048" — a manifest may list more than one value, and the flag clears if any of them matches. Neither includes 101050, so both are flagged today.

Which means the flag is silenced by editing one line of a text file. We are not suggesting you edit another author's manifest — we are pointing out what that says about the signal. A health check that one text edit can switch off was never measuring health.

The "Allow out of date add-ons" checkbox does not exist any more

It was removed in 2021 and the behaviour changed with it. The ESOUI dependency sticky, fetched 2026-08-22, verbatim: "The checkbox “Allow out of date add-ons” (2, see 1st screenshot above) was removed with the update to Blackwood! The game will just put a notification into your ingame notifications once after an API version change, if you got addons which are considered to be "out of date"." The out-of-date sticky corroborates it in its own words, fetched the same day, verbatim: "Allow Out Of Date Addons is Removed" ... "Without this checkbox all mods will load regardless of the Out Of Date notification and you will need to deactivate them from the character screen if you are troubleshooting any issues."

The live interface documentation agrees. The AddOnManager object still exposes GetLoadOutOfDateAddOns (apidoc_101050.txt line 24287), plus ShouldWarnOutOfDateAddOns (24320) and ClearWarnOutOfDateAddOns (24264) — but there is no SetLoadOutOfDateAddOns anywhere in the 29,475-line dump (measured 2026-08-22). The getter survived; the setter is gone. That is exactly what removing a checkbox from the UI looks like from the outside.

Two ESOUI pages disagree on this, and it is worth naming rather than quietly picking one. The install FAQ, fetched 2026-08-22, still says verbatim: "If any of the mods in the list that pops up say "out of date" or some such, choose the "Load Outdated AddOns" option." That FAQ is stale. The measurement in the interface documentation breaks the tie, and it breaks it against the FAQ.

The practical consequence is the one most people have backwards: your out-of-date addons did not stop loading. They load. If they disappeared from your screen, something else happened — most often a hard dependency that is missing or switched off, which shows as red "Dependency", not as "Out of Date".

How little the flag means — in ESOUI's own words

The out-of-date sticky states it flatly, fetched 2026-08-22, verbatim: "As you can see by the above points "Out of Date" is completely meaningless in the grand scheme of things." The list it is summarising includes, verbatim: "- That the mod will not have errors", "- That the mod was abandon", "- That the mod author needs to update the mod to work with the current API". Those are things the flag does NOT tell you.

The measurement backs that up. Of the 3,099 addons in our snapshot with a readable ## APIVersion, 2,704 declare a value below 101050 (data/addon_deep.json, built 2026-08-22, feed retrieved 2026-08-19). The flag is the normal state of the catalogue, not an exception worth alarm.

What actually breaks: functions the game removed

The real failure mode is an addon calling something that no longer exists in the client. That is not guessable from a date or a version line — it is readable from the addon's own Lua, and we scan for it. Across the same 3,163-addon snapshot, 228 addons call at least one function the live build no longer has (scan built 2026-08-22).

A worked instance: Pithka's Achievement Tracker calls StartGroupFinderSearch, which last existed in interface version 101038 — well before the current 101050. That is a specific, checkable prediction about where it will error, and it is the kind of thing the out-of-date flag will never tell you, because that addon would carry the flag whether or not the call was there.

The inverse matters just as much: an addon can be years behind on its ## APIVersion line and call nothing that was removed, in which case it commonly still runs. That is an inference from its code, not a play-test — we read what it calls, we do not run it.

How fast do addons actually update after a patch? (measured)

Measured against the live patch date, 2026-06-08 (Update 50), across all 3,163 addons in the feed snapshot: 3.5% shipped a release within 7 days; 6.9% within 30 days; 12.5% within 60 days (data/addon_deep.json update_lag, built 2026-08-22).

Read the complement, because it is the number that should change your behaviour: 87.5% of the catalogue shipped nothing at all in the sixty days after the patch. "It hasn't been updated since the patch" is therefore not a signal — it is the majority condition. Anyone treating a missing post-patch release as evidence of abandonment is flagging seven addons in eight.

Waiting or abandoned: our rule, its cut-off, and what it rests onUnverified

This is our rule, not a documented one. We are stating it because "check if it's still maintained" is useless advice without a threshold, and the measured curve above shows the obvious threshold ("did it ship since the patch?") is wrong. Treat it as an inference from two measurements, and disagree with it if you have better information about a specific addon.

The discriminator is not the release date; it is whether the code calls anything the client removed. If it calls nothing removed, there is no deadline — 87.5% of the catalogue is in that state and much of it runs fine. If it calls something removed, waiting does not help: only a new release fixes it, and the addon will keep erroring in the meantime.

The calendar cut-off we use is the next interface bump, because that is when the question actually changes: Update 51 goes live on PC/Mac on September 28, 2026. An addon that has shipped nothing by then has sat through two interface bumps without its author touching it. That is the point at which we would start looking for a replacement rather than waiting — still not proof of abandonment, but the first moment the wait has a real cost.

• Calls nothing removed, no release since the patch → wait. This is the normal state of 87.5% of the catalogue.
• Calls something removed → do not wait. It needs a release; nothing you do at your end fixes it.
• Nothing shipped by 2026-09-28 (Update 51 live) → start looking for a replacement. Two bumps untouched.
• In every case: the last-release date on the author's page is the only responsiveness signal that exists. It is weak. We do not dress it up as more.

The addon has vanished from the site entirelyUnverified

Here is exactly what our data can and cannot tell you, because the honest answer is "less than you want". Our feed snapshot is the public MMOUI v3 API — the same feed Minion reads — retrieved 2026-08-19, carrying 3,163 addons across 38 categories. "Outdated & Discontinued" is not one of those 38 categories. The category exists on ESOUI (the sticky quoted above is literally titled "Out Of Date Addons / “Outdated & Discontinued” addon category"), but nothing in it reaches our snapshot.

The consequence is blunt: an addon moved into the discontinued category and an addon deleted outright look identical in our data. Both are simply absent. Our absence is not evidence of removal, and it is not evidence of anything else either.

The fates people describe — retired by the author, renamed, adopted by a new maintainer, absorbed into the base game, or pulled for breaking site rules — are the possibilities, and our dataset distinguishes none of them. What settles it is the addon's own page on ESOUI, which our feed no longer carries once the listing leaves the feed. If you have the old URL, that page is the thing to check.

One recovery risk worth stating: a re-upload under a similar name is not verifiable as the same code by anything we hold. And a file tagged [Console] on esoui.com is not an install route at all — the troubleshooting sticky says so verbatim, fetched 2026-08-22: "If you find addons here on esoui.com named like [Console]* or similar, this is just for source code reference".

Your accumulated data survives all of this — here is where it lives

Before the first step, not after it. The ESOUI request sticky, fetched 2026-08-22, verbatim (typo in the original): "SavedVariablse are stored in live/SavedVariables but we do not have access to the files directly, only via the ZO_SavedVars wrapper class". Same post, verbatim: "They are copied in internal game memory and only read from that memory, saved to the disk on a reloadui or zone change with a loading screen. Any altered data on the disk file will be overwritten from internal game memory at that point!"

Two practical consequences. First: updating or deleting an addon's folder in live\AddOns does not touch its settings, which sit in live\SavedVariables. Second: if you want to back them up or edit them, do it with the game closed, or the client will overwrite your edit from memory at the next zone change.

The record of which addons are enabled is a separate file one level up. The troubleshooting sticky, fetched 2026-08-22, verbatim: "Search for UserSettings.txt or AddOnSettings.txt file on your harddrives/sdds and check which folder it is in (with the most up2date date and time!). Below this folder, in the subfolder AddOns, your addons need to be located so the game will find them as well." The same post names the two environment problems it blocks on, verbatim: "OneDrive is not supported within ESO!" and Windows Defender controlled-folder access preventing the file being written.

Which parts of this do not apply to you

All of the above is the PC/Mac add-on list and the PC/Mac file layout. Console works differently at every step: there is no folder to open, and no external installer. ESOUI's console sticky, fetched 2026-08-22, verbatim: "You cannot use Minion or any other download source to install them to your console. To download and install AddOns on your console you must use the ingame addon browser on your console!"

Input mode changes one thing in the error popup rather than in this flag: the troubleshooting sticky notes the control is "the "Show more" checkbox (keyboard mode) / the "More info" keybind (gamepad mode)". If you are on a controller, that is the difference you will see.

Check your whole installed set in one pass

Looking your addons up one at a time is what makes this take an evening. Paste your AddOns directory listing into the folder checker and it returns, per folder you actually have: the declared interface version, whether it is flagged, whether it calls anything removed, and which required folders are missing. That is the difference between knowing about the catalogue and knowing about your game.

What this guide cannot tell youUnverified

Whether any specific addon works. We read manifests and scan code for calls the client removed. We do not run addons, and no measurement here is a play-test.

Why a particular addon left the catalogue. Our feed snapshot cannot distinguish retired, renamed, adopted, absorbed or removed — all five look the same as absent. Only the listing's own page settles it.

When any given author will ship. The last-release date is the only signal that exists and it predicts nothing. Our 2026-09-28 cut-off is our rule, chosen because it is the next interface bump, not a documented threshold.

Whether the 12.5%-in-60-days curve holds for the next patch. It is one measurement, against one patch date (2026-06-08), across one snapshot (n=3,163).

Anything sourced to ZeniMax about the out-of-date mechanism. Their Add-On Terms of Use page returned only "This page is under translation." on 2026-08-22 and their support knowledge base served no article text to a plain client the same day. Everything above is ESOUI's own documentation plus our own measurements of the game's interface documentation.