Emergency · 60-minute triage
Base44 app not working — run this 60-minute triage.
Confirm the symptom, run the matching playbook, escalate at the 60-minute mark. Each symptom branch deep-links to a documented /fix/[slug] playbook with explicit time budgets. If you have less than an hour, this is the page. If you have an afternoon, see /base44-debugging-help.
Short answer
If your base44 app is down right now, the protocol is: confirm the symptom in the first 15 minutes, run the matching playbook in the next 30 minutes, escalate to urgent help if unresolved at the 60-minute mark. Match your symptom to one of the ten branches below — white screen, 500 error, function timeout, login broken, data missing, webhooks not firing, Stripe failing, AI-agent regression, deploy failed, editor hangs — and follow the three timed sub-steps. Each branch deep-links to a documented playbook on /fix. If you have an afternoon rather than an hour, use the decision-rubric page at /base44-debugging-help instead.
01 / First 15 minutes — universal checks
Run these three before you pick a branch.
About one in three inbound emergencies is solved by the universal checks alone. Running them first prevents wasted effort on the wrong branch.
Check 01 · 2 minutes
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.
Check 02 · 5 minutes
Function logs
404s and 405s point at routing breakage; 429s point at rate-limit throttling; 500s usually point at function code or missing env-vars. Note the dominant code before picking a branch.
Check 03 · 5 minutes
Auth flow
Sign in as a fresh test user from incognito. If sign-in fails, go straight to the auth branch. If sign-in works but the app still breaks, the issue is downstream and another branch applies.
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).
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.
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.
Function timeout / function stops working after hours
- Confirm symptom · 1 minute
- Functions worked at deploy time but stopped silently after a few hours. Most often the symptom is 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 default config is bypassable by header manipulation; check whether your remediation from the July 2025 disclosure is still in place. 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 the bypass open. If first-line confirmation surfaces a real issue, escalate immediately rather than trying to patch.
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.
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.
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.
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.
Symptom not in this list? Browse the full 47-entry /fix index for other documented playbooks, or jump to urgent help.
03 / Hourly time budget
Budget the 60 minutes — 15, 30, 15.
The single most 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 three 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.
For most outages, the 60-minute protocol either resolves the issue or surfaces 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, route directly to /hire-urgent-base44-developer or start a sprint at /fix. Money-back if the sprint cannot resolve the issue.
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. Use /base44-debugging-help to score whether the structural fix is DIY-able or needs an engagement, and /audit to scope the production hardening pass that prevents the same class of failure from recurring.
QUERIES
Frequently asked questions
Q.01I have less than 60 minutes — where do I start?
Skip to the symptom that matches what your users are seeing. Each branch has three timed sub-steps: confirm the symptom (1 minute), run the first-line fix (10 minutes), escalate to urgent help (at the 30-minute mark if unresolved). Do not run more than one branch at a time — if the symptom changes mid-triage, restart the protocol from the top.
Q.02Why does this protocol cap at 60 minutes?
Past the 60-minute mark, the cost of continuing to triage usually exceeds the cost of hiring help. Either the symptom is platform-side and not fixable from your side, or the root cause is on a layer that needs a senior engineer. Either way, a calm 60-minute protocol followed by escalation produces better outcomes than a frantic three-hour DIY session.
Q.03What if my symptom is not in the list?
Run the three universal checks (status page, function logs, auth flow) under the 'first 15 minutes' section. If they come back clean, browse the full /fix index — there are 29 documented playbooks across 11 categories. If you still cannot match a symptom, book the 15-minute urgent call and we will scope on the spot.
Q.04What 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 /base44-debugging-help when the fire is already out and you are planning the structural fix.
Q.05Should I roll back instead of fixing forward?
If you have a known-good build from the last 24 hours, yes — roll back first, fix forward second. The triage branches below assume rollback either failed or is not available. If a rollback is available and you have not tried it, that is your first 5-minute action regardless of symptom.
Q.06How fast can urgent help respond?
For genuine production emergencies — payments down, auth broken, app fully unreachable — urgent help responds inside two business hours during weekday working hours. Flag 'urgent' on the contact form or use /hire-urgent-base44-developer. Out-of-hours response is best-effort.
NEXT STEP
Get unstuck this hour.
If the protocol did not resolve your issue, route directly to urgent help — response inside two business hours during weekday working hours. For non-emergency triage, see /fix pricing.