Check these first
Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.
- 1
Hard refresh, then try a private window. Ctrl+Shift+R or Cmd+Shift+R. If the private window shows the new version and your normal window does not, it was your browser cache and you are done. Do this first every time — it costs ten seconds and resolves a good share of these.
- 2
Check whether the assets are actually there. Open the live site, open the browser's network tab, reload, and look for any JS or CSS file returning 404. If the page HTML loads but the asset hashes 404, the publish did not complete properly — this exact failure took a production site down for 16+ hours in September 2026, with "publish completes successfully but built JS/CSS assets aren't pushed to the CDN". It is not your code, and no amount of re-editing will fix it.
- 3
Check the console for MIME type or module errors. A blank screen with a MIME type complaint is a serving problem, not a logic problem. Base44's troubleshooting page lists these.
- 4
Are you signed in on one and not the other? The editor preview usually has you authenticated. The live site, in a private window, does not. If the live site is blank for a signed-out visitor, that is your auth configuration behaving correctly — and it is also what search engines see.
- 5
Are you on a branch? Publishing happens from main only. If you have been working on a branch, the change is not in the published app and never was.
- 6
Check environment variables and secrets. They differ between the sandbox and production, and names are case sensitive. Base44's docs also note that local dev tokens are rejected in production because "The local dev server signs tokens with a local secret. Your deployed app uses a different secret".
- 7
Check status.base44.com. From inside your own app a platform incident looks exactly like your own bug, and you can lose a whole day to that.
Set this in your dashboard
Dashboard → Branches. Confirm which branch you are actually on before you spend an hour wondering where your change went. Publishing is from main.
Dashboard → Secrets and environment variables. Compare what exists in production against what your code expects, name for name and case for case. This is a two-minute check that solves a surprisingly common "works for me" case.
Dashboard → Checkpoints. If the live site broke after a publish and you cannot see why, restoring the previous checkpoint and republishing is faster than debugging forwards — and it gets your users back online while you investigate.
Backend functions require the Builder plan or above. If your functions 404 in production and you are on a lower plan, that is the reason, and no code change will help.
There is no CDN purge button. If you find yourself looking for one, you are at the point where the answer is either wait, or raise it with support.
Why this happens on Base44
The editor preview and your published app are two different runtimes. They run different builds, on different infrastructure, with different authentication state and different environment variables. Treating them as the same thing is what makes this class of problem so disorienting — you have tested it, it works, and the thing other people see is not the thing you tested.
What actually differs:
Build and cache. The published site is served from a CDN, and Base44's docs are explicit that "you can't clear the CDN cache manually". So when something is stale, waiting and hard-refreshing are genuinely the tools available.
Authentication. You are almost always signed in inside the editor. Your visitors are not. Half of "it's blank on the live site" is an app behaving exactly as configured for a signed-out person.
Environment. Secrets and variables are not the same in the sandbox as in production, and the names are case sensitive. A missing variable usually fails silently rather than loudly.
Branch versus main. Publishing is main-only. Work on a branch is not in the published app, and a branch also uses your real live data — so it is possible to be simultaneously confused about why the change is missing and unsurprised that the data looks right.
And sometimes the publish itself fails while reporting success. That is the one worth knowing about, because every instinct sends you back into the editor to change things that were never wrong. The tell is asset hashes returning 404 on the live site while the HTML loads. If you see that, stop editing and raise it — you cannot fix it from your side.
Then run this
Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.
Open Base44, opens in a new tabBase44 links on this page are affiliate links. If you sign up through one, Dean may earn a commission at no extra cost to you.The divergence audit — read only, changes nothing
My app behaves differently in the editor preview and on the published live site.
Find every reason the two could diverge.
READ ONLY. Do not edit, create or delete any file. Do not publish or deploy. Do
not change any configuration. If something should change, describe it.
EVIDENCE RULE — this governs everything below.
Every finding must carry one of:
[CODE] a file path and line number
[LIVE] a URL you fetched, with the HTTP status code you received
[UNVERIFIED] you could not check it from here
No PASS or "this is fine" without evidence. Never assume production behaves like
the sandbox — that assumption is the bug I am asking you to find.
1. IS THE LIVE SITE SERVING WHAT THE BUILD PRODUCED
- Fetch the published site root. Status code.
- Extract every script and stylesheet URL from the returned HTML. Fetch each
one and report its status code. Any 404 here is the headline finding and
…73 lines · 3,451 characters
The fix prompt — only after the audit says it is your code
Using the audit you just produced, fix the divergence. The audit was read-only; this turn is the only one that writes. FIRST, A GATE. If the audit concluded this is a platform problem — assets 404ing after a successful publish, or anything else outside this project — do not attempt a workaround. Tell me so again in one line and stop. I would rather raise a support ticket than have you paper over it with code that I then have to maintain. Otherwise, in this order: P0 anything that breaks the app for signed-out visitors or new users P0 missing or wrongly-cased environment variables P0 backend functions that cannot start in production P1 hardcoded sandbox, preview or localhost URLs P1 code that assumes a record or a user exists P2 caching and staleness Rules: …
40 lines · 1,827 characters
Run this only after you have read the audit above, and only when you are happy for it to change files.
The publish proof — run after you publish, every time
I have just published. Verify what is actually live, not what the editor shows.
FETCH EACH OF THESE FRESH AND REPORT THE RAW RESULT
1. The live site root: HTTP status code.
2. Every script and stylesheet URL in the returned HTML: status code for each.
Any 404 means the publish did not fully land — say so first and loudest.
3. The asset hashes in the live HTML versus this project's latest build output:
do they match, or is the live site serving an older bundle?
4. The live root fetched with no authentication: does a signed-out visitor get
the app, a login page, or an empty shell?
5. The two or three routes I changed most recently: does the response contain
the new content?
6. /robots.txt and /sitemap.xml: status codes.
For each, PASS, FAIL or UNVERIFIED. Where a fetch contradicts what the previous
turn claimed, the fetch wins — say so plainly and show the value you saw.
THEN, WHAT I MUST DO MYSELF
…33 lines · 1,693 characters
An agent that reports its own work as done is not evidence. This pass re-checks from outside the change.
What this can’t fix
Give the cache a chance before you conclude anything. There is no manual CDN purge. Hard refresh, private window, and a few minutes resolves a real share of these, and it costs nothing to rule out first.
Test as a stranger, not as yourself. A private window signed out, and ideally a brand new account with no data. Most "works for me" bugs are really "works for an account that has been using this app since it was built".
If the assets are 404ing, stop editing. That is a publish that reported success without delivering. Nothing you change in the editor will fix it. Raise it with support with the evidence — the failing asset URL and its status code — and say what you have already ruled out. A builder lost 16 hours to this in September 2026; the detail that made it diagnosable was "a fresh build succeeds locally and produces a valid dist/assets folder, but publish doesn't upload it to the live CDN".
Know your rollback before you need it. If a publish breaks the live site, restoring the previous checkpoint and republishing puts your users back before you start investigating. Debug the broken version afterwards, not while people are looking at it.
Do not fix a symptom you do not understand. A blank screen wrapped in a loading spinner is worse than a blank screen, because now it fails silently forever. If you cannot explain why it was blank, you have not fixed it.
Links you’ll need
- Base44 — troubleshootingBlank screens, MIME type errors, ISOLATE_INTERNAL_FAILURE, backend function 404s, and the full HTTP status code table.
- Base44 — app performance"Currently, you can't clear the CDN cache manually." Worth knowing before you spend an hour trying.
- Base44 — backend troubleshootingWhy local dev tokens are rejected in production: different signing secrets.
- Base44 — working with branchesPublishing is main-only, and a branch uses your real live data.
- Base44 status pageFirst check, every time. A platform issue is indistinguishable from an app issue from inside the app.
Asked in the Base44 Discord, 15 Sept 2026. Facts on this page verified 15 Sept 2026. v1. Google and Base44 both change things — if something here has gone stale, tell me.