Base44 Backend Functions Stop Working After Deploy

What's happening

When Base44 backend functions stop working hours after a successful deploy, the cause is in your logs, not on a timer. Base44's documentation does not list idle recycling as a cause of function failures. It documents these: ISOLATE_INTERNAL_FAILURE when a later save or deploy hits a file in your /functions folder that cannot start in Base44's Deno environment, scheduled automations paused automatically after they keep failing, a 5-minute maximum execution time after which runs are terminated, credit-using actions that pause when the app reaches its credit limit, function 404s that a redeploy clears, and platform changes recorded in the changelog. Open Logs in your app dashboard and filter to Function Call with Errors only, or run base44 logs --env prod in a terminal, then fix the cause the error names and re-enable anything Base44 paused.

You deploy. Everything works. You test buttons, the forms submit, the data saves. Six hours later a customer emails: nothing works. You open the app and confirm. The save button does nothing. The dashboard does not load. The webhook endpoint returns 500.

A user on the feedback board described this exactly: "Features suddenly stop working after a few hours...my app is completely unusable."

The symptom points at the clock, but the documented causes do not. Something changed between the deploy that worked and the request that failed: a save or deploy, a schedule that kept failing, data that grew, a credit balance that ran out, or the platform itself. Each one leaves a trace, which is where the fix starts.

Why this happens

Base44 backend functions run on Deno, and each function gets its own HTTP endpoint. Base44 documents six things that produce the work-then-fail pattern.

A later save or deploy fails with ISOLATE_INTERNAL_FAILURE. Base44's Troubleshooting page says you might see this error "when you try to save or deploy a backend function", and that it "usually means that one of the files in your /functions folder does not follow the platform requirements and cannot start in Base44's Deno environment." The common causes it lists are a function file without a Deno.serve() entrypoint, utility or empty files inside /functions, imports of frontend components, shared project utilities or other backend functions, and Node.js built-ins (such as fs, path, process and crypto) or browser-only APIs that the Deno runtime does not support. The function worked at deploy; a later change, such as an AI edit that added a helper file or a new import, is what broke it.

A scheduled automation kept failing and Base44 paused it. From Base44's product changelog (June 7, 2026): "Scheduled automations that keep failing are now paused automatically. You receive a notification when this happens and can re-enable the automation once the issue is resolved." Apps created from July 6, 2026 use workflows instead of automations, and the same rule applies with numbers attached: a scheduled workflow is deactivated after 5 consecutive failures, a workflow with any other trigger after 50, and Base44 emails you when it happens. A job that ran fine for days and then went silent may simply be paused.

The job outgrew the 5-minute limit. "Backend functions have a maximum execution time of 5 minutes, enforced the same way whether the function is called directly, triggered by an automation, or invoked as a workflow step. Requests that exceed this limit are terminated." A sync or report that finished in two minutes on launch data can pass five minutes as your tables grow, and from then on every run is cut off.

The app reached its credit limit. Base44's credits page: "When you reach your credit limit, actions that use credits pause until your next reset." Built-in services such as sending an email or running an LLM call use integration credits, and running a backend function can use a small amount for the invocation itself, so a function that worked yesterday can stop doing its work today.

Every function route returns 404 after a deploy. When all your backend functions return 404, the Troubleshooting page says it "usually points to a problem with your app's routing or deployment, not your code or configuration", and its fix list includes redeploying from the dashboard "to trigger a fresh deployment and update app routing."

A platform change. Base44 records platform changes in its product changelog and developer changelog, and you can follow both by RSS or on Discord. Some changes alter behaviour that code relied on. On September 2, 2026, for example, a row-level security rule that checks something about the signed-in user started denying access when that value is empty or cannot be resolved; before, it matched records where the field was missing. A function or screen that reads data as the signed-in user can return fewer records after a change like that, with nothing changed on your side.

Sources: Base44 docs — Troubleshooting, backend functions overview, Logs page, CLI logs command, workflows, credits; feedback.base44.com posts "Angry at B44" and "Critical Bug/SDK Missing".

How to reproduce

1. Note when the first failure happened and what runs the function: a button, an incoming webhook, or a schedule.
2. In your app editor, click Dashboard, then Logs. Filter the event type to Function Call and turn on Errors only. Expand the failing row: Error shows the message and Outputs shows what the function returned.
3. From a terminal, run base44 logs --function yourFunction --level error --env prod --since 6h. Without --env prod the command reads the preview deployment, not your published app. Add --app-id with your app's id if you built the app in the online editor and never linked it locally.
4. For a scheduled job, open Workflows in the dashboard (or Automations on apps created before July 6, 2026). Look for a workflow that is no longer active and for failed runs in its Run history or on the Activity tab.
5. Call the function yourself: curl -X POST https://your-app.base44.app/functions/yourFunction -H "Content-Type: application/json" -d '{}', or open Dashboard → Code → Functions, select the function and click Test Function.
6. Match what you see to a cause: ISOLATE_INTERNAL_FAILURE on save or deploy is a file problem, a schedule with no recent runs is a paused automation, runs that fail at about five minutes are the time limit, and a 404 from every function is routing.

Step-by-step fix

1. Read the error before you change code

The Logs page and the CLI's logs command show the same failures from two sides. The Logs page records function calls alongside integration and automation executions, so you can see whether the function ran at all. base44 logs returns the most recent entries across your functions and filters by function name, time range or log level; add --follow to stream new entries while you reproduce the failure. Write down the exact error message before you try any fix below.

2. Fix ISOLATE_INTERNAL_FAILURE at the file level

Work through Base44's own fix list for the error:

• Make sure every function file has a Deno.serve() entrypoint.
• Move empty files and pure utility modules out of /functions, so only real functions live there.
• Remove imports of frontend components, shared project utilities and other backend functions; keep only imports from supported npm packages.
• Replace Node.js built-ins such as fs, path, process and crypto, and any DOM or window APIs.
• Save and publish, so the functions are rebuilt and deployed.

If the error persists, the docs suggest pasting the function into the Base44 AI chat with a prompt such as: "This backend function returns ISOLATE_INTERNAL_FAILURE. Make it self contained and compatible with Deno.serve without changing what it does."

3. Read secrets inside the handler and log every failure

Base44's backend functions docs are explicit: "Call secrets.get() inside your handler, not at the top level of your module. Secrets resolve per request, so a read at module load, before any request runs, returns undefined." Wrap the handler body in try/catch as well, so every failure leaves an error line in the logs (console.error shows up as ERROR in base44 logs).

import { createClientFromRequest } from "npm:@base44/sdk";
import { secrets } from "base44:runtime";

Deno.serve(async (req) => {
  try {
    // Read secrets per request, inside the handler.
    const apiKey = secrets.get("PARTNER_API_KEY");
    if (!apiKey) {
      console.error("[saveOrder] missing secret PARTNER_API_KEY");
      return Response.json(
        { error: "config_missing", key: "PARTNER_API_KEY" },
        { status: 500 },
      );
    }

    const base44 = createClientFromRequest(req);
    const body = await req.json();
    // ... validate body, call the partner API with apiKey, write with base44.entities
    return Response.json({ ok: true });
  } catch (err) {
    console.error("[saveOrder] uncaught:", err);
    return Response.json(
      { error: "internal", message: err instanceof Error ? err.message : String(err) },
      { status: 500 },
    );
  }
});

This turns an opaque 500 into a JSON error body and a log line you can search for.

4. Re-enable paused automations once the cause is fixed

Base44 notifies you when it pauses a failing automation and leaves re-enabling it to you, "once the issue is resolved". Fix the error the failed runs show first, then turn the automation back on. On apps that use workflows, open Dashboard → Workflows, click the More actions icon on the workflow and click Activate; fixing and reactivating a workflow resets its failure count. Then use Run now to confirm it succeeds.

5. Keep every run under 5 minutes

The 5-minute ceiling applies to direct calls, automations and workflow steps alike. Log each run's duration, and when a job gets close to the limit, split it: process one batch per run, store a cursor in an entity, and let the next scheduled run continue from there. The base44 function timeout error playbook covers the patterns.

6. Redeploy when every function returns 404, then escalate

Base44's checklist for function 404s: test the function from Dashboard → Code → Functions → Test Function, confirm you are on the Builder plan or higher, check that each function file uses Deno.serve(), then redeploy from the dashboard. If the 404s continue, the docs call it "likely a platform-level routing or deployment issue rather than something wrong with your app setup" and ask you to contact support with the app link, the affected function names, screenshots of the errors and when the issue started. The backend functions 404 fix walks through it.

7. Watch the changelog and add an external alarm

Subscribe to the product and developer changelogs by RSS, or follow them on Discord, and check them for the dates around your first failure. For alerting, point an external uptime monitor (UptimeRobot, BetterStack, or a Vercel cron) at a small health-check function every 5-10 minutes, so you hear about a failure before your customers do. Each ping is a function invocation; Base44's credits page says 100 invocations use about 1 integration credit, and notes that this billing can differ between workspaces.

# Health-check request for your uptime monitor
curl -X POST https://your-app.base44.app/functions/healthcheck \
  -H "Content-Type: application/json" \
  -d '{"ping": true}' \
  --max-time 10

Keep a functions.md file listing every function URL, its expected request shape and when it last worked, so you can tell in seconds which function failed rather than testing them one by one.

DIY vs hire decision

DIY this if: You have fewer than 5 backend functions, you are comfortable reading Deno error output, and you can spend an afternoon on logging and monitoring setup.

Hire help if: Your app handles payments, your function failures are causing customer-facing outages, or you have already redeployed three times and the failures keep returning. We typically harden a function fleet in a 48-hour sprint: every function gets the try/catch wrapper, env-var validation, an external monitor, and a documented health-check endpoint. We also instrument response-time tracking so the next failure is visible before customers see it. If the logs show runs cut off at the 5-minute limit, work through the base44 function timeout error playbook in parallel — the symptoms overlap and the fixes layer cleanly.

Need this fixed in 48 hours?

Our fix-sprint hardens your entire backend function fleet against the after-hours failure pattern: try/catch wrappers, lifted env reads, external monitoring, and a redeployment runbook for the next time it happens. Fixed price, 48-72 hour turnaround, includes a health dashboard.

Start a fix sprint for failing functions

Related problems

• Backend functions return 404 — routing is broken — when every function returns 404 and the cause is routing or deployment rather than your code.
• Production throttle from 429 rate-limit errors — a sibling failure that compounds when you add retries.
• No SLA below Enterprise — your app is one outage from down — the structural reason platform-side failures hit so hard.
• Emergency response when the whole app goes dark — when the diagnosis turns up a full outage and you need to escalate fast.