Emergency · 60-minute triage
Base44 app not working: run this 60-minute triage.
For founders whose live Base44 app is broken right now: six checks, a symptom table and one timed branch per symptom, each linked to a documented fix playbook. Escalate at the 60-minute mark. Urgent help runs at the same prices as scheduled work, from a $1,500 fix sprint, acknowledged inside two business hours.
Short answer
If your Base44 app is not working, run six checks first: status.base44.com for a platform outage; an incognito reload to rule out your own browser; the first red error in the console; Revert or Version History if it broke after an AI edit; production secrets, then a fresh publish; and the function logs, read by status code. Then match the symptom to one of the 13 branches below — each links a documented fix playbook and runs to a 60-minute budget. If you have an afternoon rather than an hour, score the problem with Base44 debugging help instead.
01 / First 15 minutes — universal checks
Run these six before you pick a branch.
Running them first, in this order, prevents wasted effort on the wrong branch. The first four mirror steps in Base44’s own troubleshooting guide; the last two read the production side of the app.
Check 01 · 2 minutes
Is Base44 down? Check the status page
Visit status.base44.com. A platform-wide outage affects everyone. If there is an active incident, the fix is to wait — no engagement needed. A green page is not the last word: Base44’s docs also point to its Discord for reported outages, and note the platform is sometimes “updating or experiencing temporary downtime.” If the page is clean and the symptom is billing, an account or a connector, it belongs to Base44’s own support channels, not to a fix sprint.
Check 02 · 3 minutes
Incognito reload, then a fresh sign-in
Open the live app in an incognito window or another browser. If it works there, the fault is local: Base44’s troubleshooting guide (checked 23 September 2026) lists clearing your cache and Base44 cookies and turning off extensions, especially ad blockers and privacy tools. Then sign in as a fresh test user. If sign-in fails, go straight to the auth branch; if it works but the app still breaks, the issue is downstream.
Check 03 · 2 minutes
The first red console error
Open the browser console (F12, or Cmd+Option+J on a Mac) and reload. Copy the first red error, not the last — errors further down are often knock-on effects. Base44’s support asks for console errors when an app won’t load, so you need it either way. No clear error at all? Base44’s docs suggest typing “Something is wrong” in the AI chat, which analyses the app and suggests fixes in context — read the diagnosis before you let it change anything.
Check 04 · 2 minutes
Roll back if it broke after an AI edit
Restore the last working version before debugging anything: the Revert icon on the chat message, or Version History (the clock icon in the AI chat). Asking the AI to undo it is not the same thing — Base44’s docs say rolling back by “asking” the AI in chat “never actually undoes prompt changes—only the Revert button or Version History will fix it.”
Check 05 · 3 minutes
Production secrets, then republish
Confirm every secret the app calls — API keys, webhook signing secrets — is set for the live app, compared against your last known-good preview. Then publish again and wait for the success message. Base44’s docs add: if you updated a backend function, redeploy it from the dashboard. If your changes still don’t show, work through the fix for a published app not reflecting changes.
Check 06 · 3 minutes
Function logs, read by status code
404s and 405s point at function routing breakage; 429s point at rate-limit throttling in production; 500s usually point at function code or missing env vars, the ground the internal server error playbook covers. Note the dominant code before picking a branch.
02 / Symptom triage flowchart
Match the symptom, follow the three timed steps.
Pick the one branch that best matches what your users are seeing right now. Each branch has three steps with explicit time budgets: confirm (1 minute), first-line fix (10 minutes), escalation criteria (at the 30-minute mark from start of branch — minute 45 of the 60-minute budget). P0 branches are the ones where users are locked out, money is moving or data is exposed.
| Branch | Symptom your users see | Priority |
|---|---|---|
| 01 | White screen / 405 error after login | P0 · urgent |
| 02 | HTTP 500 / internal server error | P0 · urgent |
| 03 | Function timeout / function stops working after hours | Standard · 60-min budget |
| 04 | Login broken / users locked out / SSO failing | P0 · urgent |
| 05 | Data missing / records not loading / RLS drift | P0 · urgent |
| 06 | Data loss when returning to the app | P0 · urgent |
| 07 | Webhooks not firing / events dropping | Standard · 60-min budget |
| 08 | Stripe failing / payments not granting access | P0 · urgent |
| 09 | AI agent regression / agent rewriting working code | Standard · 60-min budget |
| 10 | Deploy failed / publish not completing | Standard · 60-min budget |
| 11 | Editor hangs / crashes on the workspace | Standard · 60-min budget |
| 12 | AI chat stuck on “Thinking…” or “applying changes” | Standard · 60-min budget |
| 13 | Works in the editor, broken on the live URL | Standard · 60-min budget |
White screen / 405 error after login
- Confirm symptom · 1 minute
- Sign in fresh from an incognito window. If the screen is white and the network tab shows a 405 on the post-login redirect (but a manual refresh fixes it), this is the auth-state race condition.
- First-line fix · 10 minutes
- Open the playbook and apply the redirect-gating fix that waits on token confirmation before navigating. Verify by signing in three times in a row from incognito with no manual refresh.
- If unresolved at 30 minutes · escalate
- If the 405 persists after the gating change, escalate. The next likely root cause is SDK token persistence — outside DIY scope.
P0 · Users blocked or money at risk? Send an urgent request →
HTTP 500 / internal server error
- Confirm symptom · 1 minute
- Open the function logs in your workspace. A 500 with no stack trace is usually an env-var miss or a routing 404 misreported as 500 by an upstream layer.
- First-line fix · 10 minutes
- Compare the production env-var set to your last known-good preview. Re-deploy with the routing playbook if env-vars match. Time-budget: 10 minutes.
- If unresolved at 30 minutes · escalate
- If the 500 survives a clean redeploy and env-vars are confirmed correct, the issue is in function code or a third-party integration. Escalate.
P0 · Users blocked or money at risk? Send an urgent request →
Function timeout / function stops working after hours
- Confirm symptom · 1 minute
- Functions worked at deploy time but stopped silently after a few hours. Look for a 504 or a hung request rather than an explicit error.
- First-line fix · 10 minutes
- Apply the cold-start + routing-decay playbook. Re-register the route, redeploy, and run a synthetic ping every 10 minutes for the first hour to catch silent decay early.
- If unresolved at 30 minutes · escalate
- If decay returns within an hour, the platform-side scheduler is the root cause. Escalate — this is not DIY-fixable.
Login broken / users locked out / SSO failing
- Confirm symptom · 1 minute
- Try sign-in as a fresh test user from incognito. If sign-in fails with a 401 / 403 or hangs on the SSO callback, you are in this branch.
- First-line fix · 10 minutes
- Read the SSO playbook. The SSO bypass that Wiz reported on 9 July 2025 let anyone register a verified account on a private SSO-only app using only its public app_id; Wix fixed it within 24 hours. The platform hole is closed, but accounts created before the fix, or drift in your own auth settings, can still let outsiders in. Audit the user list for accounts whose email domain falls outside your SSO allowlist.
- If unresolved at 30 minutes · escalate
- Auth fixes are not DIY territory — a wrong fix leaves outside accounts inside the app. If first-line confirmation surfaces a real issue, escalate immediately rather than trying to patch.
P0 · Users blocked or money at risk? Send an urgent request →
Data missing / records not loading / RLS drift
- Confirm symptom · 1 minute
- Records vanished from a list view, or users are seeing rows they should not see. Both symptoms point at Row-Level Security drift after an AI-builder edit.
- First-line fix · 10 minutes
- Do not 'fix' this with another AI edit — it usually deepens the drift. Open the RLS playbook and run the coverage matrix to identify which predicates were skipped.
- If unresolved at 30 minutes · escalate
- RLS drift on multi-tenant apps is a silent data-leak risk. Escalate after confirming the symptom — this belongs in a fix sprint, not a 30-minute patch.
P0 · Users blocked or money at risk? Send an urgent request →
Data loss when returning to the app
- Confirm symptom · 1 minute
- Records the user just created vanish when they reopen the app. The state did not persist; this is distinct from RLS-driven invisibility.
- First-line fix · 10 minutes
- Open the data-loss playbook. Check whether the create call returned a successful 2xx and whether the row exists in the database. If the row is missing, you have a write-side bug; if present, a read-side filter is the cause.
- If unresolved at 30 minutes · escalate
- If the row is missing entirely, escalate immediately — recovery has a recency window and time matters.
P0 · Users blocked or money at risk? Send an urgent request →
Webhooks not firing / events dropping
- Confirm symptom · 1 minute
- Background events that worked yesterday are not firing today, or are firing only when a user is actively logged in. This is the documented 'webhooks require active users' platform behaviour.
- First-line fix · 10 minutes
- Open the playbook. The architectural workaround is a queue + replay layer; that is a sprint, not a 30-minute fix. The 30-minute mitigation is a synthetic active session on a heartbeat.
- If unresolved at 30 minutes · escalate
- If the queue + replay design is needed (anything revenue-touching), escalate to a sprint.
Stripe failing / payments not granting access
- Confirm symptom · 1 minute
- Customers report paying without getting access, or webhooks from Stripe are returning 4xx in your handler logs. Both point at a post-update signature regression.
- First-line fix · 10 minutes
- Open the Stripe integration playbook. Verify the webhook signature secret matches the current Stripe-side endpoint. If it does, check the access-grant chain on the Base44 side at /fix/base44-stripe-subscription-not-granting-access.
- If unresolved at 30 minutes · escalate
- Revenue-critical. Escalate the moment the first-line check confirms the signature regression — do not re-deploy a patched handler without a second pair of eyes.
P0 · Users blocked or money at risk? Send an urgent request →
AI agent regression / agent rewriting working code
- Confirm symptom · 1 minute
- Each AI-agent fix pass introduces a new defect or rewrites code that was previously working. Credits are burning at an unusual rate.
- First-line fix · 10 minutes
- Stop the agent immediately. Do not run another fix pass — each pass tends to compound the regression. Roll back to the last known-good revision if available.
- If unresolved at 30 minutes · escalate
- Regression loops are multi-bug rescue territory. After the rollback, escalate — do not attempt to debug forward through the loop.
Deploy failed / publish not completing
- Confirm symptom · 1 minute
- The publish flow hangs, errors out, or completes but the new build does not appear in production. Check the workspace status indicator and the function logs.
- First-line fix · 10 minutes
- Re-deploy with the routing playbook to clear stale route registration. If the publish still fails, check status.base44.com — platform-wide publish issues happen.
- If unresolved at 30 minutes · escalate
- If the publish hangs and the status page is clean, escalate. Stuck publish flows usually need platform-side intervention.
Editor hangs / crashes on the workspace
- Confirm symptom · 1 minute
- The base44 editor is slow, hanging, or crashing on save. Usually correlated with project size past a certain threshold.
- First-line fix · 10 minutes
- Open the performance playbook. Reduce the editor footprint by archiving unused components and tightening prompt scope. This is mechanical work — usually fixable in an hour.
- If unresolved at 30 minutes · escalate
- If the editor remains unusable after the footprint reduction, escalate. The remaining options are off-platform development workflows, which are sprint work.
AI chat stuck on “Thinking…” or “applying changes”
- Confirm symptom · 1 minute
- The chat has sat on “thinking”, “applying changes” or “undoing” with no update, and the preview has not moved. Base44’s docs note a complex first prompt can sometimes take 10 to 15 minutes, so check the clock before you intervene.
- First-line fix · 10 minutes
- Click Stop, then Revert the last chat message or restore from Version History, and resend the request split into smaller prompts. Base44’s troubleshooting guide says that if the processing state lasts longer than 10 minutes, click Stop and tell support where the AI got stuck, the prompt you ran and how long it lasted. If Stop itself does nothing, Version History is the fastest way back. The Base44 error reference separates a queued message from a genuinely stuck one.
- If unresolved at 30 minutes · escalate
- If generation dies partway through the same request every time, the sandbox is running out of execution budget — that is the playbook linked here. If each retry breaks something that used to work, the symptom has changed: restart from the top and take the AI-agent regression branch.
Works in the editor, broken on the live URL
- Confirm symptom · 1 minute
- The editor preview behaves; the published URL shows old content, a blank screen, or errors the preview never threw. Check it from a second browser or device so a cached bundle is not fooling you.
- First-line fix · 10 minutes
- Run the publish checks from Base44’s troubleshooting guide: clear the cache and reload, confirm you clicked Publish and saw the success message, redeploy any backend function you changed, and read the error logs in the dashboard. The four causes that differ between editor and live — a stale function deploy, a missing production env var, a cached old build, an auth domain that is not allow-listed — are laid out in why a Base44 app works in the editor but breaks when published.
- If unresolved at 30 minutes · escalate
- If the live build still differs after a confirmed publish and a function redeploy, the remaining suspects on that list are a production env var that was only ever set in preview, and a live domain missing from your login provider’s allow-list. Both need someone reading the app’s configuration, not another publish — escalate.
Symptom not in this list? Browse the full index of 47 Base44 fix playbooks for other documented failure modes, or send an urgent request.
03 / Hourly time budget
Budget the 60 minutes — 15, 30, 15.
A common triage mistake is overshooting the first-line fix budget. Past the 45-minute mark you are usually chasing the wrong root cause. The escalation step exists for a reason — use it.
| Time range | Phase | What you are doing |
|---|---|---|
| 0-15 min | Identify | Run the six universal checks. Match the symptom to a branch below. If no branch matches, browse the full /fix index. |
| 15-45 min | First-line fix | Run the matching playbook end-to-end. Do not switch branches mid-stream. Capture before/after in the function logs. |
| 45-60 min | Escalate | If the playbook did not resolve, hand off to urgent help. Do not run a second branch — the symptom may be downstream of a deeper issue. |
04 / When to call urgent help
Three triggers that should bypass the protocol.
The 60-minute protocol is built to either resolve the issue or surface a clear escalation point. For three classes of symptom, skip the protocol and call urgent help on the first confirmation.
Auth bypass actively in use
Logs show accounts with email domains outside your SSO allowlist that you did not provision. Treat this as a live security incident — do not patch in production yourself.
Revenue actively losing
Stripe webhooks failing and customers paying without access. Every minute past confirmation is a refund or chargeback risk. Escalate the moment the first-line check confirms the symptom.
Data leak in progress
Users reporting they can see records belonging to other tenants. RLS drift in production is a regulatory event in some jurisdictions — do not attempt the fix yourself.
For all three cases, send an urgent request now. What happens next is set out on the page for hiring an urgent Base44 developer. Acknowledged inside two business hours (9am-6pm Eastern, Mon-Fri). Same prices as scheduled work — no urgent surcharge. Three urgent slots held every week.
Urgent work is priced as a $1,500 Base44 fix sprint for one high-impact issue, or a $3,000multi-bug rescue for 3–8 related defects. Money-back if the sprint cannot resolve the issue, including a Base44 platform bug with no workaround. If a Base44 update breaks the fix within 90 days, we re-fix it at no charge.
05 / After the fire is out
The post-incident pass that prevents the next 3 a.m. call.
Once the immediate symptom is resolved, the highest-leverage follow-up is a structural review. The DIY-or-hire debugging guide scores whether the structural fix is DIY-able or needs an engagement, and a $497 Base44 production audit scopes the hardening pass that prevents the same class of failure from recurring.
QUERIES
Frequently asked questions
Q.01Why is my Base44 app not working?
The six universal checks on this page test the usual causes in order. The platform itself is updating or down. Your own browser is serving a stale cache or an extension is interfering. The last AI edit broke code that used to work. A production secret or a backend function was never set or redeployed for the live app. Or a data rule (row-level security) or the login setup changed. The checks take 15 minutes. After that, the symptom table sends you to one timed branch.
Q.02Is Base44 down right now?
Check status.base44.com first: it is Base44's own status page, and it lists each part of the platform (application preview, builder, data, file serving, hosting, login, published applications) with any active incident. A green page is not the last word: Base44's troubleshooting docs say “Sometimes the platform is updating or experiencing temporary downtime.” If the status page shows an incident, wait for it to clear before you change anything. A fix you ship during an outage is one you cannot test.
Q.03When should I stop debugging and get help?
Stop at the 60-minute mark, or at once if one of the three triggers fires: an auth bypass in use, revenue being lost, or one customer seeing another's data. Past the 60-minute mark, the cost of continuing to triage usually exceeds the cost of hiring Base44 developer help. By then the symptom is either platform-side and not fixable from your side, or on a layer that needs a senior engineer. A calm 60-minute protocol followed by escalation produces better outcomes than a frantic three-hour DIY session.
Q.04What if my symptom is not in the list?
Run the six universal checks under the 'first 15 minutes' section: status page, incognito reload and a fresh sign-in, the first console error, a rollback if it broke after an AI edit, production secrets and a republish, then the function logs. If they come back clean, browse the Base44 fix playbook index: there are 47 documented playbooks across 11 categories. If you still cannot match a symptom, send an urgent request and we will scope it with you.
Q.05What is the difference between this triage and the debugging help page?
This page assumes the app is down right now and you have less than an hour to act. It is symptom-driven and time-budgeted. The debugging help page assumes you have an afternoon to assess and decide between DIY and hire; it is decision-driven and untimed. Use this page for emergencies. Use the DIY-or-hire debugging guide when the fire is already out and you are planning the structural fix.
Q.06Should I roll back instead of fixing forward?
If it broke after a change and you have a known-good version, yes — roll back first, fix forward second. In Base44 that means the Revert icon on the chat message or Version History (the clock icon in the AI chat); Base44's troubleshooting docs are explicit that asking the AI in chat to undo a change never actually rolls it back. That is Check 04 of the universal checks, ahead of every branch. The triage branches below assume the rollback either failed or is not available.
Q.07How fast can urgent help respond?
Urgent help is for production emergencies: payments down, auth broken, or the app unreachable. Acknowledged inside two business hours (9am-6pm Eastern, Mon-Fri). Same prices as scheduled work — no urgent surcharge. Three urgent slots held every week. Send an urgent request with the symptom, the branch you reached and the first console error.
Q.08Why isn't my Base44 app loading?
Base44's own troubleshooting docs put it plainly: “Most loading issues are caused by a problem in your app’s code or a temporary platform issue.” That covers a blank white page, an endless spinner, or an app that loads briefly and then disappears — in the preview or on the published URL. Their order is: refresh or open a new window, clear your cache and cookies, check your connection, switch browser or device, revert your most recent edits if the problem started after them, and wait a few minutes in case the platform is updating (checked 23 September 2026). If it still won't load, the six universal checks on this page add the console, secrets and function-log reads that separate a bug in your app from a platform fault.
NEXT STEP
Get unstuck this hour.
Protocol run and the app is still down? Send an urgent request with the symptom and the branch you reached. Acknowledged inside two business hours (9am-6pm Eastern, Mon-Fri). Same prices as scheduled work — no urgent surcharge. Three urgent slots held every week.