AI App Builder Background Jobs (2026): What Runs When Nobody Is Watching

Quick Answer

Every builder here can run code. Almost none of them can run it while nobody is there, and that is the difference that breaks apps after launch. The nightly digest, the hourly sync, the trial that expires on day 14: all of it needs something to wake up on its own.

Three questions decide it, and only the first is obvious: does the work run without a session, where is the schedule actually written down, and whose permissions does it run under.

The second one is the sleeper. It decides whether your schedule leaves with your code or stays behind in somebody's dashboard.

• 

  Base44 is the only builder here that puts the schedule in your repository. Automations live in a function.jsonc next to the function, take standard 5-field cron expressions, and deploy atomically with the code: if an automation fails to register, the whole function deployment rolls back.

• 

  Replit ships two different things with similar names, and the one you find first is the wrong one. Routines schedule the assistant inside a Conversation and explicitly cannot be created inside a project. Scheduled Deployments are the real job runner.

• 

  Softr, the no-code option, has the finest granularity of anything in this comparison: a recurring trigger that fires every minute. Its timezone picker defaults to Los Angeles, which is a real source of off-by-eight bugs for teams outside the US.

• 

  Bubble has the deepest scheduling model and the most unusual shape: a recurring event has to be attached to a database record, and it runs with a user in context, so your privacy rules apply to your own background job.

• 

  Lovable has real scheduled jobs with run history, but you cannot create one from the jobs screen. You create it by asking in chat or by writing SQL.

• 

  Bolt.new documents a server runtime and no way to trigger it on a clock. Every use case in its own server-functions documentation is request-triggered.

• 

  Webflow had native workflow automation and removed it. Logic was sunset on June 27, 2025 and disabled on every site.

• 

  v0 describes scheduled agents and even specifies which credential they run under, while publishing no interval setting, no run history and no cron syntax anywhere in its documentation.

Why "can it run background jobs" is the wrong question

Ask a builder whether it can run code on a schedule and you will nearly always get a yes. The yes is close to meaningless, because it covers at least four different architectures that fail in different ways.

Consider what actually has to be true for a nightly summary email to arrive at 7am. Something must hold a clock. That clock must survive your browser closing, your laptop sleeping, and your project going idle for six hours. When it fires, something must decide which user's data the job can see. If the job crashes at 3am, something must tell you. And if you leave the platform, the schedule itself has to come with you, or you will rebuild it from memory.

Those are four separate mechanisms, and builders implement them at four different layers. Some put the scheduler in the database. Some put it in a separate deployment. Some put it in a workflow editor attached to a record. One put it in a feature they later deleted.

The practical version of the question is not "can it", it is: if I close every browser tab and go on holiday for a week, what still happens, and who is it happening as?

Axis 1: whether the work needs somebody to be there

The first split is between work that runs on a clock the platform holds and work that only runs because a session is open.

The trap that catches everyone on Replit

Replit is the clearest case in this comparison because it ships two features that both look like the answer.

Routines are the one you find first. A Routine is a scheduled run attached to a Conversation, and Replit's own documentation is unusually direct about the boundary. "Routines remain part of that Conversation and cannot be created inside a Project." Each run returns its results to that Conversation. "A Routine remains personal to you. It inherits the Conversation's permissions and access to connected tools." They run at intervals of one hour or more, and there is a hard cap on how many you can have active (Replit Routines documentation, 2026).

The decisive line is the one about publishing: "Routines can schedule work that Replit can complete in a Conversation. They cannot schedule publishing." A Routine is the assistant doing your chores on a timer. It is not your application doing anything.

Scheduled Deployments are the real answer, and they sit somewhere else entirely. They "run a command on a schedule in your app's environment, then stop until the next run", you describe the schedule in plain language such as "every weekday at 9am", and Replit converts it. Configuration covers the schedule, a job timeout, and build and run commands. You get an alert if a run fails (Replit deployment types documentation, 2026).

Then comes the sentence that tells you what you are really buying: "Scheduled Deployments don't serve a web page, so they have no public URL."

Your background job is a separate deployment from your web app. It is not a corner of the app you already shipped. That has consequences for cost, for how you share code between the two, and for how many things you are now operating.

The platforms that hold the clock for you

Lovable, Base44, Bubble and Softr all hold the clock at the platform level, and the work runs whether or not anyone is looking.

Lovable's Jobs are "scheduled background tasks, used when your app needs to perform recurring work such as checking for new information, posting updates, or syncing data", living in the built-in Cloud backend. The Jobs view shows each job's schedule in plain language, its last run, and a run history table with start time, end time and status of Succeeded, Failed or Running (Lovable Jobs documentation, 2026).

There is an operational detail here worth more than the feature list. Lovable auto-pauses Cloud projects after a period of inactivity, and its documentation notes that "scheduled jobs and other background activity keep a project active". So a job is not only work, it is a heartbeat. Its own FAQ points out the flip side: if a project exists only to run jobs you no longer need, disable the jobs or pause it manually, or it will keep itself awake indefinitely.

The ones that do not hold a clock at all

Bolt.new documents server functions in detail, describing them as handling "important work behind the scenes, like talking to your database, checking permissions, or processing payments". Read the use cases it lists and every single one is request-triggered: handling payments, receiving webhooks from Stripe or GitHub, generating images on demand, calling external AI APIs, sending transactional email, building messaging bots (Bolt server functions documentation, 2026).

There is a runtime. There is no documented clock to invoke it. We checked its server-functions page and its Supabase integration page, and found zero occurrences of cron, schedule, recurring, trigger or invoke across both. That is a claim about what Bolt publishes as a supported path, not a claim that scheduled work is impossible in code Bolt generates.

v0 is the more interesting negative, and it needs stating precisely. Its documentation bundle contains no cron, no background job, no scheduled job, no task queue and no worker. But it is not silent on the idea: it describes building "a Slack agent that sends me a daily summary of my merged PRs" and says the agent "posts on schedule", and it specifies the credential model such work uses, "a shared app account, one credential the whole app acts through, as itself; this is how bots and scheduled agents run" (v0 documentation, 2026).

So v0 names the use case and answers the identity question, while documenting no interval setting, no run history, and no scheduling syntax. The schedule is something you describe to an agent rather than something you configure. The identity question has a second half worth following: a job running under one shared app credential still has to read that credential from somewhere, and the platforms differ sharply on whether a stored value can be read back at all, which is covered in how each builder stores API keys and secrets.

Webflow is the only one where the capability actively went away. Its native workflow automation tool, Logic, was sunset. "As of June 27, 2025, Logic is disabled on all Webflow sites. You can't add new Logic flows to new or existing sites. Existing Logic flows are disabled and any forms previously connected to Logic flows are now standard Webflow forms." Webflow points users at Zapier and Make instead (Webflow Logic sunset documentation, 2025).

Webflow Cloud, its newer serverless platform for full-stack apps on Next.js and Astro, publishes three storage types and no scheduling primitive in its help centre overview.

Axis 2: where the schedule is actually written down

This is the axis nobody checks, and it is the one that decides what happens on the day you leave.

In your repository, versioned with the code

Base44 is alone here, and the design is genuinely good. Automations are configured in a function.jsonc file that sits alongside the backend function, and each function can carry several. Four types are supported: cron, simple interval schedules, entity events fired when database records change, and connector events from services like Gmail (Base44 automations documentation, 2026).

Cron automations take standard 5-field syntax. The scheduling fields are more expressive than anything else in this comparison: schedule_mode distinguishes recurring from one-time, and ends_type lets a recurring schedule stop never, on a given UTC date, or after a set number of executions.

Then the part that matters most:

Source, verbatim: "The deployment is atomic per function. A function is only considered deployed if both the Deno deployment and all its automations succeed. If any automation fails to deploy, the entire function deployment is rolled back."

Your schedule is code. It is reviewed in a pull request, it travels with the repository, and a broken schedule fails the deploy instead of silently not running.

In a chat message, or in SQL

Lovable's Jobs screen is a review surface, not a creation surface. Its documentation is explicit: "Creating a job, changing its schedule, or deleting one happens by asking Lovable in chat or through SQL, not from the Jobs view." You enable, disable and inspect from the dashboard; you author by conversation.

The SQL escape hatch is the important half. It means the schedule lives in the database rather than in an opaque platform setting, which is a considerably better position to be in than it first appears. But there is no file in your repository that describes it, so a code review will never show you that a job exists.

Lovable also documents a second path for heavier work: an Inngest connector for "background jobs, scheduled tasks, and durable workflows", explicitly using your own Inngest credentials on a workspace-level connection (Lovable Inngest integration documentation, 2026). That is the one arrangement in this comparison where the orchestration layer is unambiguously yours, because the account is.

In a deployment configuration

Replit's Scheduled Deployments store the schedule as deployment configuration alongside a job timeout and the build and run commands. It is not in your repository and it is not in your database. It is a property of a deployment that produces no public URL.

In an editor, attached to a record

Bubble's recurring events are defined in the backend workflow editor and can be set to None, Daily, Weekly, Monthly, Quarterly or Yearly. That is the coarsest granularity in this comparison by a wide margin.

The structural surprise is that a recurring event "requires a thing to run on". You pick a data type, and the schedule attaches to a record rather than existing globally. The clock starts when the event is first triggered by a Set or cancel a recurring event action, and the interval is calculated from that moment onward (Bubble recurring event documentation, 2026).

That per-record shape is powerful for things like subscription renewals, where every customer legitimately needs their own timer. It is awkward for a plain nightly report, which has no record to belong to. It also comes with per-plan limits counted per thing rather than per app, which is unusual enough to check before designing around it.

For work that does not fit a fixed interval, Bubble's answer is recursive API workflows: a workflow whose last action reschedules itself. Its documentation notes this "will consume more workload" but allows dynamic recursion times.

In a dashboard, with the best granularity here

Softr's workflows each start with exactly one trigger, and two of the built-in triggers are time-based: a one-time schedule that runs once at a chosen date and time, and a recurring schedule (Softr trigger types documentation, 2026).

The recurring frequencies are the finest in this comparison: every 1, 5, 10, 15, 20 or 30 minutes, hourly, daily, weekly or monthly. There is a "run on weekends" toggle, which is a small thing that saves real work.

There is also a genuine trap. The timezone selector defaults to Los Angeles time. If you are in Europe and you set a daily 9am digest without touching that field, it will arrive at 6pm.

Nowhere you can see it

For v0 there is no answer to this question, because there is no documented surface where a schedule is stored or displayed.

For Webflow the answer used to be Logic and is now Zapier or Make, which means the schedule lives in a third-party account with its own billing and its own export problem.

Axis 3: whose permissions it runs as, and what stops a runaway

A background job is code with no user in front of it, which raises two questions that request-handling code never has to answer: who is it, and what stops it.

Bubble is the only builder here that treats this as a first-class design decision. A recurring workflow "is run with the current user in context. All privacy rules apply accordingly." Your own background job is subject to the same privacy rules as a logged-in user, which is a sane default and a common source of confusion when a job mysteriously sees nothing. There is a checkbox to bypass it: "Sometimes you want the workflow to bypass these rules and be run as an admin user who has all rights on the data, even when run without authentication." Bubble flags it as a security setting to use with caution, and it is right to.

Replit's Routines answer the identity question differently: a Routine is personal to you and inherits the Conversation's permissions, which is precisely why it is not an application feature.

On runaway protection, Bubble is again the most candid, because its scheduler is shared infrastructure and it says so:

Source, verbatim: "The scheduler is a queue, and can be imagined as a funnel. If a funnel is filled with water faster than the rate at which it drains, it will be congested and it will affect its flow."

Its guidance follows from that: heavy database operations on large lists are taxing, long chains of dependent actions slow things down, and if you schedule many workflows at once you should space them out deliberately (Bubble API workflow scheduler documentation, 2026). Bubble also documents a recovery procedure for a recurring event that gets into a loop rescheduling itself: pause the scheduler, bulk delete the extraneous tasks, unpause.

One more Bubble detail that has caught many teams: the Live and Development environments have separate schedules. A job you tested in development is not a job that is running in production.

The other platforms lean on metering rather than queue management. Lovable's jobs consume Cloud usage per run, so frequent or long-running jobs raise credit usage, and its project monitoring can alert you when a scheduled job fails. Replit gives each Routine run a budget and checks it after each step, and notes that because it finishes a step already in progress, "a run can therefore go slightly over its budget". Replit's Scheduled Deployments take an explicit job timeout, which is the most direct runaway guard in the comparison.

The comparison table

The details that decide whether it works at all

The environment split. Bubble's separate Live and Development schedules mean a tested job is not a running job. Base44's atomic deploy is the opposite arrangement: the schedule ships when the code ships, or neither does.

The timezone default. Softr defaults to Los Angeles. Base44's cron ends dates are specified in UTC. Bubble's timezone override is not available until you enable timezone override controls in your app's general settings first. Three platforms, three different defaults, and every one of them is a plausible way to send a 7am email at the wrong hour.

What happens when a run fails. Lovable shows a run history with per-execution status and can alert you through project monitoring. Replit alerts you if a Scheduled Deployment run fails, and a Routine that fails asks for attention in its Conversation. Bubble surfaces upcoming scheduled workflows in the Logs tab. Bolt and v0 document nothing here, which follows from documenting no scheduler.

Whether it is one thing or two. On Replit your job is a second deployment with its own base fee and its own lifecycle. On Base44, Lovable, Bubble and Softr the job is part of the thing you already have.

Polling versus instant. Softr is unusually transparent that its own database triggers are instant with no polling delay, while several third-party integration triggers poll, with Airtable listed at a one-minute interval. If your workflow reacts to an external system, the trigger latency is part of your schedule whether you planned it or not.

One job almost everybody eventually needs. Built-in analytics on these platforms has a short retention window, and Base44's own API documentation tells you to "read the aggregates you need on a schedule and keep them yourself". That is a scheduled job whose whole purpose is to outlive a deletion policy, and it is a good first test of whichever scheduler you pick. We compare the retention windows and export surfaces in what each builder's analytics actually records.

Verdict, September 2026

If your schedule matters as much as your code, use Base44. It is the only builder here that treats a schedule as a versioned artifact rather than a setting. Cron expressions, end conditions, and a deployment that rolls back if the automation does not register. When you leave, the schedule leaves with you because it is a file.

If you want the finest granularity with no code, use Softr. A one-minute recurring trigger beats everything else in this comparison, including the developer-oriented options. Set the timezone before you set anything else.

If your scheduled work is genuinely per-customer, Bubble's shape is the right one. Recurring events attached to a record are unusual precisely because most schedulers are global, and per-record timers are exactly what subscription and trial logic wants. Accept that you are sharing a queue, and space your work out.

If you are on Replit, learn the two names. Routines will not run your app. Scheduled Deployments will, as a separate deployment with a timeout and no public URL. Confusing them costs a day.

If you are on Lovable, the jobs are real, and remember they keep the project awake. Author by chat or SQL, review in the Jobs view, and disable jobs you no longer want rather than leaving them to hold a project open.

If you are on Bolt.new or v0, plan to bring your own scheduler. Both generate real code you can host anywhere, so an external scheduler is a normal solution rather than a workaround. Just do not assume from a yes that a clock is included.

If you are on Webflow, this decision was made for you in 2025. Native automation is gone and the supported answer is a third-party tool. Budget for it.

The question to ask any of them before you commit is not whether background jobs are supported. It is: show me where the schedule is stored, and tell me what happens to it if I export this project tomorrow.