Guides

Background Jobs

Run asynchronous tasks and background processing with MUDBASE.

MUDBASE Functions are serverless — you write the code, MUDBASE runs it in response to a trigger and executes retries and scheduling for you. There's no separate "jobs" product to set up: a function with a cron or event-based trigger is your background job.

Scheduled jobs (cron)

Deploy a function with a cron trigger to run it on a schedule. Pick a preset — minutely, hourly, daily, weekly — or supply a custom 5-field cron expression:

json
{
  "trigger": {
    "type": "cron",
    "schedule": "0 */6 * * *"
  }
}
{
  "trigger": {
    "type": "cron",
    "schedule": "0 */6 * * *"
  }
}

The scheduler checks for due functions every minute and executes them with invokedBy: "cron" — there's no separate cron worker to run or maintain.

Event-driven jobs

Instead of polling, trigger a function directly from an event so it runs the moment something happens:

  • document — a document is created, updated, or deleted in a specific collection
  • file — a file is uploaded or deleted in a specific bucket
  • webhook — an inbound webhook is received
  • wallet — a monitored wallet sees a new tx or a balance change
  • messaging — a message is sent or received
  • http — called directly, like a normal API endpoint (GET/POST/PUT/DELETE)

For example, a function with a document trigger on the orders collection's create event runs automatically every time a new order document is inserted — no polling, no queue to manage.

Retries and execution history

A failed execution is retried automatically; retryCount and the full execution log (duration, success/failure, what triggered it) are visible from Console → Functions for every run, so you can debug a failure without adding your own logging.

Warning
Function code runs in an isolated sandbox with no database, storage, messaging, or network access — it only receives payload, context, and env, and returns a value. That return value is recorded on the execution's history entry and used for run/error stats and billing — it is not sent anywhere as a response, and it isn't used to perform further side effects like writing to a collection or sending a message. Invoking a function (including via an http-type trigger) is fire-and-forget: the invoke call returns immediately with a queued executionId, and you read the eventual result back out by polling the execution log rather than getting it in the response body. If your job needs to actually change something beyond what it returns, do that from your own backend after reading the function's execution result via the API, rather than from inside the function's code.

See Webhooks for the inbound-webhook event model a webhook-triggered function reacts to, or Realtime Events for pushing results back to connected clients once a job finishes.