- last edited on by
computergeek541
Hi all! Adding a consolidated report so PM can fix this for everyone.
What users are seeing
Multiple members (e.g., @Blessing05 , @Roxymike200 , @Paulmcc881 ) are getting the “OUR SERVICES ARE GETTING AN UPGRADE” banner with dates March 4–5 when trying to log in today (late July). The Go To Login Page button drops to the public landing page. The site/app also appears down right now.
Why this is happening (technical)
I checked the login page with DevTools:
The UI reads two endpoints that control this banner:
…/status (maintenance window text)
…/user/session/expiration-time (a timestamp)
Current responses show:
expiration-time returns a live timestamp for today.
status still returns the old March 4–5 window.
Neither endpoint sends Cache‑Control headers in the responses captured (HAR available). Without explicit directives, the CDN/browser/service‑worker caches the JSON far too long, so users keep seeing a months‑old maintenance notice.
Net effect: a stale banner is rendered even when the site is down for a different reason today. It’s confusing, and from a security standpoint stale notices can be spoofed by phishing pages.
What Public Mobile should change
@CS_Agent please escalate to the platform team:
Purge the CDN cache (and any service‑worker cache) for /status and /user/session/expiration-time.
Add strict caching headers on both JSON endpoints, e.g.
yamlCopyEditCache-Control: no-store, must-revalidate(or at minimum max-age=0, stale-while-revalidate=60), and ensure server/edge override.
Add a “Last updated <UTC/local time>” stamp to the banner so users can tell it’s current.
Fix the Go To Login Page CTA to route to the actual login when services are up.
Consider a dedicated status page (separate endpoint) with live incident timestamps to avoid reusing old copy.
Happy to share the HAR summary if needed; it shows 200 OK on both endpoints with no Cache‑Control and the stale March window in /status.
What customers can do right now
The site/app is currently down, so there’s nothing to do immediately.
For future stale‑banner issues, try:
Clear browser/app cache, or use Incognito/Private.
Update/reinstall the PM app from the official store.
Always start at publicmobile.ca or the official app (avoid old shared links).
Need to pay during an outage? Buy a payment voucher and dial 611 on your PM phone to redeem by IVR (works even when self‑serve is down).
Sidenote, Respectfully, issues like this shouldn’t have to be caught by volunteers in the Community. When a brand is publicly called out, it’s a reminder to take cybersecurity seriously, fix the root cause, tighten cache/CDN policies, and prevent the same failure from recurring.
For everyone else, a few safety habits while PM sorts this out:
Trust only official entry points: type publicmobile.ca yourself or use the official app.
Treat stale banners as suspicious: if a notice shows months‑old dates, don’t follow buttons on that page.. reopen a fresh tab and navigate manually.
Check the lock/domain: confirm https:// and the publicmobile.ca domain before entering credentials or payment details.
Use private windows for account access during odd errors (bypasses cached assets).
Never post personal/account info here; share only with CS_Agent via secure ticket.
If you must pay during outages: buy a payment voucher and dial 611 to redeem by IVR.
I'm flagging this to help PM reduce confusion and risk for customers. A quick cache/header fix, and a purge, will restore trust fast.
Thanks for taking a look and helping clean this up. It’ll reduce support load and improve trust for everyone. 👍
— Cpt_Captcha
