Base44 errors fall into seven categories: generation errors (sandbox timeouts, unsupported dependency rejections, hallucinated entity fields), deployment errors (build failures, ISOLATE_INTERNAL_FAILURE on backend functions, the 405 routing bug), runtime errors (white screens after login, blank pages, 500s on functions, stale cache — see why a Base44 app crashes repeatedly), data and entity errors (5,000-record list cap, missing field references, MIME validation failures), authentication errors (email verification loops, OAuth callback mismatches, expired tokens), integration errors (Stripe webhook signature failures, custom integration deprecation), and platform-wide outages and rate limits. This reference catalogs 70+ specific errors with one-line fixes, including the strings people paste into Google verbatim — ISOLATE_INTERNAL_FAILURE, rate limit exceeded, message queued, 'dict' object has no attribute 'lower', and the UnicodeEncodeError that stops the app editor opening at all. If Base 44 is not working and you have no error string to search on, start with the sixty-second triage below. Deeper diagnosis lives in the linked /fix/ pages.
Why base44 errors are hard to diagnose without a reference
Most Base44 error troubleshooting is fragmentary. The platform's docs cover some errors — the Troubleshooting page improved during 2026 and now carries an Error Codes section for seven HTTP statuses (200, 400, 401, 403, 404, 429, 500) plus named entries for a handful of platform strings — but those entries are spread across eight collapsible sections with no flat list to scan, and the failures that cost real money in production are not among them. Feedback boards have user-reported errors with mixed-quality answers. Stack Overflow has a few. Nowhere is there a complete reference. This article, maintained by the lead engineer at Base44Devs, aggregates what we have observed across audit engagements with one-line fixes per error.
The fixes here are surface-level. For errors that need deeper diagnosis — AI-agent regression loops that keep breaking working code, an editor that hangs and crashes on large apps, stored XSS that leaks authentication tokens — the row links to the relevant /fix/ page where we go deep. Use this reference as the first lookup; escalate to the linked page when the one-liner doesn't solve it.
How to use this base44 errors reference
- Find your error in the table by symptom or message.
- Read the cause column to confirm the diagnosis matches your case.
- Apply the fix.
- If it doesn't work, follow the
/fix/link for deeper guidance.
If the one-liner does not hold and the linked playbook is more than you want to take on yourself, a fixed-price Base44 bug-fix sprint closes one named issue in 48–72 hours.
We update this list quarterly. If you hit an error not in the list, contact us and we'll add it.
Why is Base 44 not working? Sixty-second triage
Some failures arrive without a string to look up. The app will not load, the chat will not answer, the editor is blank — nothing to paste into Google. Work this ladder in order before you touch any code. It takes about a minute and it settles the only question that changes what you do next: is this the platform, or is this your app?
- Check
status.base44.comfirst. If the platform is having an incident, everything below is wasted effort and no amount of reverting will help. The status page only reflects platform-wide outages, so a green status does not mean your app is healthy — it means the failure is narrower than the whole platform. - Type
Something is wrongin the AI chat. This is a documented feature almost nobody uses: Base44 analyses what is happening inside the app, surfaces the issues it finds, and suggests fixes in context. It is the fastest way to convert a vague failure into a specific error string, which is what the rest of this reference is organised around. - Look for the Issues Found notification. When Base44 detects a JavaScript error in your preview, an Issues Found notification appears with the error and where it occurred. Clicking Resolve with AI sends those details into the chat, and per Base44's documentation that action does not count toward your message credits. It is the one diagnostic the platform gives you for free — take it before you spend credits guessing.
- Revert with the button, not with a prompt. If the app broke on a specific change, hover that message in chat history and click the Revert icon, or open Version History and roll back. Asking the AI in chat to "revert" or "undo that" does nothing to your app — only the Revert icon and Version History actually roll anything back. This is the single most common wasted hour in Base44 debugging.
- Stuck on "Thinking…" after the very first prompt? The app has usually been partially created. Clone it — Dashboard > Settings > App settings > Clone app — and open the clone. If cloning does not help, create a new app and paste the same prompt again. Worth knowing before you panic: a complex first prompt can legitimately take 10 to 15 minutes.
- Prompt running with a dead Stop button? Version History is the fastest route back. If you would rather not lose the work: change the model in your app settings, switch to Discuss mode and send anything at all ("hi") to break the wedged state, or make a trivial Edit-mode change — an extra space in a text block — to force a state transition. If the processing state has run past 10 minutes with no update, click Stop and open a ticket with where it got stuck, the prompt you sent, and how long it ran.
One banner worth naming, because it is searched constantly: Error while processing your message, please try reverting your last message. The instruction in it is literal — use the Revert icon on that message rather than sending a follow-up prompt asking the AI to fix itself. Community reports of this banner sometimes show a provider-level suffix appended to it (litellm.ServiceUnavailableError), which points at the upstream model provider being unavailable rather than at anything in your app; when that is what you see, waiting it out or switching the model in app settings is the entire fix.
If every step above comes back clean and the app is still broken, the failure lives in your own code rather than in the platform. That is the point at which the tables below, and the /fix/ playbooks behind them, are the right next stop.
Base44 message queued: what it means and when it is actually stuck
"Message queued" is not an error. When the AI chat is already working on a prompt, anything else you type is added to a queue and sent one at a time as each response finishes. The queue renders above the chat input and lists the pending prompts in the order they will run. Base44 documents a ceiling of seven queued messages at once.
The reason this phrase gets searched at all is one documented behaviour that looks exactly like a freeze: queued messages do not send if you close the app editor. They are not lost — reopen the editor and any queued messages resume — but if you lined up five prompts, closed the tab, and came back expecting the work to be done, nothing will have happened in the meantime. That single sentence is the answer to most "my Base44 queue is stuck" reports.
The queue is editable rather than fire-and-forget. You can drag and drop to reorder it, edit a queued message inline before it sends, remove an individual message, clear the whole queue, or pause and resume it. If you queued something you no longer want, deleting it from the queue costs nothing; letting it run costs credits.
Genuinely stuck is a different state with a different fix. Queued means your message is waiting behind a prompt that is still running. Stuck means the running prompt itself is not finishing — the chat sits on "Thinking…", "applying changes" or "undoing" and the queue never advances because nothing ahead of it completes. That is the state the triage ladder above addresses: Stop button, then Version History, then a model switch plus a throwaway Discuss-mode message to break the wedge. The practical test is whether the count of pending messages above the input is going down. If it is, you are queued and waiting. If it has not moved in ten minutes, you are stuck, and the queue is a symptom rather than the problem.
Generation and build base44 errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Sandbox timeout during AI build | Generation hangs, then errors with "sandbox timeout" | Single prompt too large for the model's context | Split the prompt into smaller scoped requests, one component at a time; the full sequence is in the Base44 sandbox timeout fix |
| Unsupported dependency rejection | "Package X is not supported" during build | Backend function imports a package not in Deno's curated list | Replace with a supported package or call the dependency over HTTP from the function; transitive and Node-API cases are covered in the Base44 unsupported dependency error fix |
| Build fails — no clear reason | Deploy fails with generic error | Most often a syntax error in agent-generated code; sometimes a platform-side issue | Check the IDE for red underlines; if clean, check status.base44.com. The three failure modes are separated in the Base44 deployment error publish-failed guide; if the agent keeps writing code that contradicts its own earlier output, see Base44 prompt conflicts |
| npm package rejected | Specific package fails import | Package uses Node-only APIs (fs, child_process) | Use a Deno-compatible alternative or move logic to client side; see the Base44 npm package rejected error fix |
| Generation timeout | Agent stops responding mid-generation | Context window exceeded or platform-side latency spike | Refresh chat, scope the next prompt narrower, snapshot before retrying; the recovery pattern for Base44's AI forgetting context mid-build goes further |
| Hallucinated field references | Code references a field that doesn't exist on the entity | Agent forgot the actual schema due to context loss | Re-prime the chat with a paste of the actual schema; see hallucinated fields fix |
Deployment and routing errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| ISOLATE_INTERNAL_FAILURE | Backend function returns 500 with this message | Deno couldn't load the function — usually a syntax error or unsupported import | Open the function in IDE, fix syntax, verify imports are Deno-compatible; the full diagnosis for a Base44 500 internal server error covers the other three causes |
| Backend function URL error in browser | "Network error" when calling functions.someFunction | Function hasn't deployed or the URL routing is broken | Verify the function shows as deployed in IDE; if yes, see routing fix below |
| 405 Method Not Allowed on POST | Function accepts POST in code but returns 405 | Routing bug where /functions/* gets caught by frontend router | Use the workaround in the linked fix article |
| Deployment failed with no clear reason | Publish completes but new code isn't live | Platform deployment partial-failure | Re-publish after a few minutes; if persistent, file ticket |
| Published changes not appearing | New code in IDE, old code in production | Browser cache or platform-side caching | Hard refresh (Cmd+Shift+R), then check via incognito to confirm; if it survives that, see a Base44 published app not reflecting changes |
| Failed to load app: Error serializing to JSON: UnicodeEncodeError | App editor will not open at all, and the app cannot be renamed | The app name contains an emoji or a special character the platform cannot serialize | There is no self-serve route out — the rename path is the thing that is broken. Contact Base44 support to have the name changed, and keep emoji out of app names |
| Domain stuck in pending | Custom domain shows "pending DNS verification" indefinitely | DNS propagation delay or wrong record type | Verify DNS via dig/nslookup; full guide in domain DNS pending fix |
| Domain stuck in Connecting | Domain sits in "Connecting" status rather than pending verification | The link did not complete platform-side | Different status, different fix: if it has been in Connecting for more than 30 minutes, open Dashboard > Domains, unlink the domain and link it again |
| ERR_SSL_PROTOCOL_ERROR | Domain doesn't load over HTTPS | SSL provisioning hasn't completed or DNS is wrong | Wait 15–30 min; if persistent, re-add the domain |
| Domain and SSL both fail with AAAA records present | Domain will not verify, or SSL errors persist, despite correct A/CNAME values | Base44 resolves over IPv4 only; an AAAA (IPv6) record on the domain breaks resolution and blocks SSL provisioning | Delete every AAAA record for the domain, then allow propagation. This is a prerequisite for the two rows above, not an alternative to them |
| New pages 404 on the custom domain only | Pages load on the .base44.app URL and 404 on your own domain | The DNS records are proxied through Cloudflare (orange cloud) rather than DNS-only | Set the Base44 records to DNS only (grey cloud) and leave them that way permanently, not just while troubleshooting; proxying also stops Cloudflare Workers running in front of the app |
| 429 on domain reconnect | Can't re-add a previously-deleted domain | Rate limited at platform level | Wait 24 hours, then retry |
Runtime errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| White screen on click / page unresponsive | Page loads, then goes blank on interaction | Unhandled JS exception in the React tree | Open browser DevTools console; fix the error; redeploy |
| White screen for authenticated users only | Logged-out users see content, logged-in see blank | Auth-dependent code throwing on a missing field | Check the User entity for missing fields; add defaults; the routing variant is a Base44 white screen and 405 after login |
| Blank screen after publishing | App was working, now blank | Field mismatch — UI references a field that no longer exists on entity | Restore the missing field or update UI to match new schema; see the Base44 data binding undefined field fix |
| App crashes on mobile | Works on desktop, crashes on phone | Memory or unsupported-API issue | Test in mobile Safari; check for desktop-only APIs (window.fs, etc.) |
| Buttons stop working after hours | Features that worked become non-functional | Often token expiry or platform-side cache invalidation | Hard refresh; if persists, re-deploy and check Token expiry handling; the cold-start isolate cause behind Base44 functions dying after hours is the other half |
| Editor hangs / extended loading | Base44 IDE itself becomes unresponsive | Project size has grown beyond efficient editor performance | Refactor large files; close other browser tabs; clear IDE cache |
| Apps fail after revert | "Unexpected error: contact support@modal.com" | Revert left runtime in inconsistent state | Re-publish current state; if needed, re-deploy from a known-good snapshot |
| 'dict' object has no attribute 'lower' | Chat error during a prompt | Platform-side issue with prompt parsing | Refresh chat, retry the prompt with simpler phrasing |
| Chat stuck on Thinking... | First prompt of a session hangs | Cold-start latency or platform-side queue | Wait 60s; if no response, refresh the chat |
| Discuss mode uses too many credits | Credits drop fast even without code changes | Each discuss-mode turn consumes credits | Switch to direct edit mode for routine work |
Data and entity errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Data disappears on return to app | Saved data vanishes when user logs back in | Often an Entity.list filter mismatch or schema change | Verify the entity still has the field; check filter; restore from snapshot. RLS, cache and write-ack causes are separated in Base44 data disappearing on return; if only a multi-step form loses its answers, that is Base44 state loss in multi-step forms |
| Cursor edit loads old version | Code edit overwrites recent changes | Editor sync issue with stale state | Refresh; manually merge via version history |
| 5,000 item limit exceeded | List call truncated at 5,000 records | Platform limit since November 2025 | Paginate with cursor on a sortable field; the same ceiling is why Base44 has no bulk delete and admin tasks stop scaling |
| RLS not restricting data | Users see records they shouldn't | RLS rules misconfigured or not applied | Audit RLS rules; test with second account; full guide in security checklist. When it appeared right after an agent edit, it is Base44 RLS drifting out of sync after an AI edit |
| Workspace move irreversible | App now in wrong workspace, can't move back | Documented platform limitation | No fix; recreate the app or contact support — the options left once a Base44 workspace move has trapped the app |
| Database schema mismatch | Code references field, error says field doesn't exist | Schema drift between code and entity definition | Update entity to match code, or vice versa; the component-side symptom is a Base44 component referencing a missing data source |
| Uncaught Error: Error in json schema: properties is required for object type | Blank screen after publishing, with this error in the console | Field definition and stored data disagree on a flexible object — the input type and the value type do not match the schema | Align the field type with what is actually being saved; only reach for JsonSchemaForm when the object's properties are known in advance |
| File upload fails — invalid MIME type | File rejected even with valid format | Browser-reported MIME type doesn't match expected | Re-encode the file or relax MIME validation server-side; silent-failure and size-limit cases are in Base44 image upload not working |
| Image does not match the provided media type | Image upload rejected even though the file looks valid | The file was renamed rather than converted — a .webp saved as .png, for example, so the extension and the actual encoding disagree | Revert the message that carried the upload, re-export the image as PNG or JPG from an image editor, then upload the exported file. Renaming an extension never converts anything |
| File upload exceeds 50MB | Large file upload fails | Platform per-file limit | Compress, split, or use external storage (S3) for large files |
Authentication errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Email verification loop | User can't get past verification step | Verification email lands in spam or platform-side issue | Check spam; resend; if persistent, contact support — or work through the Base44 email verification loop fix |
| Google OAuth redirects to error | Google login fails after consent | OAuth callback misconfigured or domain mismatch | Verify allowed origins/redirects in both Google Cloud and Base44; the real cause is usually the one in Base44 Google auth not working. Same class of break for Facebook login on Base44 and for GitHub, Microsoft and Slack OAuth |
| Forgot password no email | Reset email never arrives | Often deliverability via shared sender pool | Use external email provider; check spam; verify email exists |
| Token expired (401 in function) | Backend SDK calls return 401 | User's JWT expired during long-running op | Catch 401, return session-expired response, force re-auth on frontend. If tokens are being stolen rather than expiring, that is stored XSS leaking Base44 auth tokens |
| User locked out | Can't log in despite correct credentials | Rate limit on failed auth or account flag | Wait 15 min; check Base44 admin panel for account state. A logout that bounces the user forever is a different bug: the Base44 infinite loop on logout |
| SSO bypass risk (pre-July 2025) | Anyone can register on private app | The patched-but-structural issue | Verify org-domain check post-signup in a backend function; the lockdown steps are in the Base44 SSO bypass fix |
Integration errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Stripe payment not processing | Checkout fails or succeeds but no record | API key mismatch (test vs live) or webhook not signed | Verify keys; validate webhook signatures; full guide in Stripe integration guide. When the charge lands but the customer still cannot get in, see a Stripe subscription not granting access |
| Webhook only fires when users active | Subscription renewals fail at 3am | Documented platform behavior — Base44 webhooks only fire while a user is active | External scheduler (cron-job.org) triggers a backend function |
| Webhook returns 500 on POST | Function deployed but webhook fails | Wrong URL, missing signature validation, or routing bug | Verify URL; check function logs; see routing fix |
| 403 on a webhook from Telegram or WhatsApp | The endpoint passes your own test call and returns 403 when the service calls it | Those services send webhook requests from their own servers and cannot attach credentials — no api_key, no custom headers — so an authenticated endpoint rejects them | The endpoint has to be public for them to reach it. Keep auth on your other integrations and expose one separate public-only function for these, scoped to actions that are not sensitive |
| Stripe in-app purchase rejection | iOS app rejected for missing StoreKit | Apple requires StoreKit for digital goods | Use native iOS shell with StoreKit; route subscriptions through it — the full path is in the Base44 App Store rejection fix |
| Hugging Face 401 from Base44 app | API returns 401 with valid key | Often token leakage or platform-side proxy issue | Move HF calls through backend function with secret in env vars |
| Custom integration deprecated | New integration won't add | Custom integrations deprecated post-March 2026 | Use a backend function calling the third-party API directly |
| Twilio SMS not sending | Send call succeeds but no message | Twilio account state, invalid number, or rate limit | Verify Twilio dashboard; check Twilio logs; the six root causes are worked through in Base44 Twilio SMS not sending |
Three integration failures need more than a one-line workaround, because the symptom and the cause sit in different systems: Base44 and Supabase sync drift, where a mirrored user or plan table quietly stops matching; a Base44 Zapier integration that stops firing, which has five distinct root causes; and a Stripe integration that breaks after a Base44 platform update, which looks like your bug and is not.
Billing and credit errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Excessive credit burn for minor changes | Small edits cost 10+ credits | Agent regenerates large code regions | Scope prompts narrowly; full guide in credit burn fix |
| Cannot purchase additional credits | UI shows option but purchase fails | Platform requires tier upgrade for more credits | Upgrade tier or wait for next cycle — the four options when you cannot buy Base44 credits mid-cycle |
| Unused credits don't roll over | Remaining credits gone at month-end | Documented platform behavior — unused Base44 credits expire rather than roll over | Plan usage to consume the allowance each cycle |
| Hidden dual subscriptions | Charged twice per cycle | Platform billing bug — UI shows only one | Contact billing support; document both invoices |
| Pricing increased post-Wix | Tier costs more than at signup | Acquisition-era pricing changes | Re-evaluate tier fit; budget 25% headroom |
| Monthly plan not unlimited despite name | Hits credit cap on Monthly tier | Platform tier mapping not what naming suggests | Read tier docs carefully; choose tier on credit allowance, not name |
Performance and rate limit errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| 429 Too Many Requests | Sudden burst of failed API calls | Platform rate limit on burst traffic | Add exponential backoff; reduce concurrency; the production version is 429 rate-limit throttling in production |
| Rate limit exceeded | The words "rate limit exceeded" during ordinary use, not under load | Base44 applies rate limits per person, so the ceiling is per-user rather than per-app — one user, one script or one repeated dashboard action can trip it alone while everyone else is unaffected | Spread requests over time instead of firing them together, batch where the integration supports it, cache repeat reads, and wait before retrying after a 429 rather than retrying immediately |
| 500 Internal Server Error from API | Sporadic failures on entity calls | Platform-side issue, or your own handler exceeding its budget — see the Base44 function timeout error and its 25-second ceiling | Retry with backoff; check status.base44.com |
| Scheduled task not running | Cron-style job doesn't fire | Platform's scheduled functions are unreliable when no users active | External scheduler triggers the function via fetch |
| Editor extremely slow | IDE laggy on every keystroke | Project size or browser memory | Refactor; close tabs; clear IDE cache |
Mobile and app store errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| App Store rejection — web wrapper | iOS submission rejected | Apple's "essentially a web view" policy | Add native features beyond the web view; or pivot to PWA-only |
| Build number not incrementing | Same IPA file rejected by App Store | Build version not updating between exports | Manually bump build number in export config |
| Push notifications not supported | Mobile users don't get notifications | Platform limitation on managed mobile builds | Use a third-party push provider (OneSignal) wired via custom code |
| Android camera missing | Camera UI doesn't appear on Android | Manifest permission missing | Add camera permission to Android manifest in build config |
Platform and workspace errors
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Platform outage | Multiple apps down simultaneously | Base44 infrastructure issue (Feb 3 2026 example) | Check status.base44.com; wait; no SLA recourse — the mitigations available while Base44 has no SLA are the only lever you hold |
| Support ticket no response | Days/weeks with no reply | Usually scope, not backlog — Base44's docs exclude app code, prompts and architecture from support | Reply on the existing thread with new detail (never a duplicate); the in-scope escalation ladder for Base44 support tickets sitting ignored is written out in full |
| Status page misleading | App down, status page green | Status page only reflects platform-wide outages | Maintain external synthetic monitor as ground truth |
| Your workspace limits imports to approved GitHub organizations | GitHub import is refused before it starts | The repository's organization is not on the workspace allow-list | A workspace owner or admin adds the org under Settings > Governance > GitHub organizations, then you paste the repository URL again. Read-only access fails for a separate reason — Base44 would have to copy the repo into your personal GitHub account and restricted workspaces block that copy — so ask for push access on the original instead |
| cdn.tailwindcss.com should not be used in production | Console warning on every page of every app | The Tailwind CDN script is injected by the Base44 platform and cannot be removed or disabled | Ignore it. It is documented platform behaviour, it does not affect functionality or security, and there is no setting to turn it off. Worth a row here only because it sends people hunting for a bug that is not theirs |
Common mistakes when handling base44 errors
Treating every error as transient. Some errors require code fixes; retrying without diagnosis just burns credits.
Ignoring the function logs. They are the first place to look for backend errors and are routinely skipped.
Not shipping logs externally. Platform logs roll quickly. Without external retention, post-incident debugging is impossible.
Using shared error messages. Wrap every SDK call in try/catch and surface user-friendly messages. Default platform errors leak implementation details.
Skipping snapshots before risky operations. Many errors are recoverable via snapshot revert. No snapshot, no recovery.
Assuming an error has to be visible. The most expensive Base44 failures never throw anything. The app does not show up in Google at all because pages render client-side; the pages that do get fetched carry no schema markup and no dynamic meta tags; and the SDK coupling that becomes vendor lock-in only surfaces on the day you try to leave. None of these appear in a log.
How common are base44 errors in production apps?
In our audit work, every production base44 app surfaces 5–15 distinct recurring errors within the first month of real traffic. The most frequent: token-expiry 401s in backend functions, the 405 routing bug on POST endpoints, white-screen failures after schema changes, and credit-burn spikes from agent regenerations. Apps that ship without external logging never see the long tail and silently lose users to errors that never get triaged.
Past a certain error volume the useful question changes shape. It stops being which error is this and becomes is this platform the right home for this app — a judgement our full Base44 review works through from the repair side, including what the keep, fix and leave decisions each cost.
Want us to triage your base44 errors log?
Our $497 audit reviews your function logs, identifies the top error patterns, and produces a prioritized fix list. Most apps have 5–15 distinct recurring error types; we resolve the top 3–5 in a 48-hour fix sprint after the audit. Order an audit or book a free 15-minute call.
Related reading
- Base44 SDK Reference — the API surface and its specific failure modes.
- Base44 Credit System Explained — billing-error diagnosis and prevention.
- Base44 Production Readiness Guide — the broader operational picture, including observability that catches errors early.