A cPanel server that has stopped updating is a server that is missing the 2026 root-escalation fixes, so an upcp failure is a security incident in waiting, not a cosmetic issue. The update script is verbose about why it stopped, but the reason is buried in a long log, and several of the 2026 causes are policy decisions (dropped operating systems, tier retirements) rather than bugs. This guide covers how to find the reason and what to do for each.
Table of Contents
Short answer: Run /scripts/upcp --force and read the first [FATAL] or blocker line in /var/cpanel/updatelogs/last; that line names the cause. An unsupported operating system such as Rocky Linux or Ubuntu 22.04 needs a migration, not a setting; a tier blocker is fixed by moving one tier at a time with whmapi1 set_tier; package errors are cleared with dnf clean all, disabling foreign repositories and /scripts/check_cpanel_pkgs --fix; and a corrupt tree is repaired with /scripts/upcp --sync.
Find the failure in the log
Run the update in the foreground so you see it live, then inspect the log:
/scripts/upcp --force
less /var/cpanel/updatelogs/last
grep -iE 'fatal|error|blocker|blocked' /var/cpanel/updatelogs/last | head -40The first [FATAL] or blocker line is the cause. Everything after it is fallout. Also check WHM » Server Configuration » Update Preferences for the tier and WHM » cPanel » Upgrade to Latest Version, which shows blockers in the interface with a short explanation.
Confirm what you are on and what you are trying to reach:
whmapi1 version
cat /etc/cpupdate.conf
cat /etc/redhat-release 2>/dev/null || lsb_release -dUnsupported operating system
This is the most common 2026 cause and there is no configuration fix; it needs a migration plan.
- Rocky Linux 8 and 9: support ended with version 134. A Rocky server stays on 133 and receives no further updates, including security builds. The supported route is the in-place conversion to AlmaLinux using the deployment script, covered in migrating Rocky to AlmaLinux.
- Ubuntu 22.04: last supported in 136. Version 138 requires 24.04. Move to 24.04 with
do-release-upgradefollowing the cPanel-specific steps, or rebuild. - CentOS 7, CloudLinux 7, AlmaLinux 8 below the required minor: the 110 tier is the last for EL7 and reaches end of life in December 2026. RHEL 9-family systems must be at 9.5 or later since 132.
- AlmaLinux 8 or 9 wanting AlmaLinux 10 features: use ELevate, covered in our ELevate guide.
The log message in these cases mentions the OS name and says the target version does not support it. Do not try to edit /etc/redhat-release or fake the version; the update will half-apply and leave a broken server.
Tier blockers
Moving between tiers has rules. You cannot skip from 110 to 138 in one hop, and you cannot go backwards. If /etc/cpupdate.conf says CPANEL=release but the server is on 110, the update logic first evaluates whether 134 is reachable on this OS before allowing 138. Set the tier explicitly and run upcp once per hop:
whmapi1 set_tier tier=134
/scripts/upcp --force
whmapi1 set_tier tier=release
/scripts/upcp --forceA blocker also appears if a feature the target version removed is in use. Version 136 removed Ruby on Rails and RubyGems support; if a server still has the ea-ruby packages installed and applications registered, the upgrade refuses until they are removed. The blocker text names the feature. Remove the packages and any app registrations with /scripts/ea_ruby_migrate or by uninstalling them from EasyApache 4, then retry.
Package and repository failures
When the log shows dnf or yum errors, the OS package layer is the problem rather than cPanel:
dnf clean all
dnf makecache
dnf check
rpm -Va --nofiles --nodigest 2>&1 | grep -v '^\.\.\.' | headTypical findings are a third-party repository (Remi, a stale CloudLinux mirror, an old MariaDB repo) with a broken metadata URL, a partial transaction left by a crash (dnf history and dnf history redo help), or a package conflict between an EA4 PHP and a Remi PHP. Disable the offending repository and rerun upcp. If cpanel- packages themselves show as modified in rpm -V, run:
/scripts/check_cpanel_pkgs --fixIt reinstalls anything cPanel considers corrupt from its own mirror.
Disk, clock and package repair
upcp needs a few gigabytes free on /usr and /var and enough RAM to run the perl installer. Check df -h /usr /var /tmp and free -m. The other silent killer is the system clock: a drift of more than a few minutes causes TLS failures against the update mirrors that look like connectivity errors. chronyc tracking should show a small offset; fix with chronyc makestep. Also confirm that outbound HTTPS to httpupdate.cpanel.net is open in CSF’s TCP_OUT.
When the log is a mess of partially applied files, cPanel provides a resync that compares every installed file with the mirror and replaces differences:
/scripts/upcp --syncIf even that fails because the local cPanel perl or the update script itself is broken, the recovery path is the installer in update mode, which reinstalls the cPanel tree without touching accounts:
cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest --forceTake a full backup first; our backup-verify script confirms the archives are usable before you rely on them.
A common pitfall: disabled auto-updates
Many servers that “cannot update” simply have updates turned off in Update Preferences from a migration years ago, and then hit multiple blockers at once because they are far behind. Set the daily updates back on:
whmapi1 set_cpanel_updates updates=daily
grep -E 'UPDATES|RPMUP' /etc/cpupdate.confUPDATES=daily and RPMUP=daily are what you want. Manual-only updates mean you are the security team, and 2026 has shown the vendor patches faster than most teams can schedule.
Verify
After a successful run, whmapi1 version reports the target build, /var/cpanel/updatelogs/last ends with a completion line and no [FATAL], and the version banner in WHM matches. Check that all services restarted cleanly with /scripts/restartsrv_cpsrvd --check and systemctl --failed. Then compare the build against the CVE-to-build mapping to confirm you are past the September bulletins. Add a weekly check of /var/cpanel/updatelogs/last to your monitoring so the next failure surfaces within days, not months.
CPanel upcp failed at a glance
![cPanel upcp Failed summary card: Run /scripts/upcp --force and read the first [FATAL] or blocker line in /var/cpanel/updatelogs/last; that line names…](https://srvscripts.com/wp-content/uploads/2026/09/upcp-failures-upgrade-blocked-unsupported-os-summary.png?v=1790802826)
Official documentation: cPanel & WHM documentation, Linux man pages.
Related guides: What changed in cPanel 138: Meridian, Ask AI, Nova, MCP and domain rename · Install ImageMagick and PHP Imagick for EA-PHP on AlmaLinux 8/9/10 (and CloudLinux CageFS) · Managing web log retention and Apache log cleanup on cPanel (v136+).
Frequently asked questions
Does a failed upcp run break the server or its accounts?
Usually not. upcp checks blockers before it changes files, and a failure at the blocker stage leaves the server exactly as it was. A failure mid-way through the file sync is rarer and is what /scripts/upcp --sync exists to repair.
How long does /scripts/upcp –force take?
A routine update finishes in ten to thirty minutes depending on how many builds behind the server is and the speed of the mirror. A multi-tier catch-up runs once per hop, and --sync or the installer in update mode can take an hour.
Can I skip cPanel versions, for example from 110 straight to 138?
No. Tier moves are one hop at a time and only forwards, and each target must support the operating system. Set the tier to the next LTS, run upcp, then set the next tier and repeat.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Last full review
- Next review
- Sources
- docs.cpanel.net