Firebase cron jobs

Firebase cron jobs for recurring product workflows

Firebase makes it easy to ship backend logic with Cloud Functions, Firestore, and Auth. The scheduling problem appears right after launch: how do you run recurring work for customers without turning cron into infrastructure you have to own?

What teams usually mean by Firebase cron jobs

Sometimes the requirement is simple. You need a nightly cleanup, an hourly sync, or a daily aggregation job. A fixed schedule that triggers one backend function can be enough.

The model changes when schedules are part of your product. A workspace picks its own report cadence. A merchant enables a recurring sync. A user pauses reminders, then changes timezone. Those schedules are no longer deployment settings. They are application data.

Where static schedules stop fitting

You need one recurring job per user, workspace, or integration.
The schedule changes from your product UI or backend events.
You need create, update, pause, resume, and delete operations through code.
You want delivery history when support needs to inspect failures.
You do not want to build a sidecar scheduler service next to Firebase.

A cleaner pattern for Firebase apps

Let your Firebase app own business logic and let an external scheduler own time-based delivery. Your backend creates a recurring webhook through an API, stores the returned job id, and handles the scheduled work in a protected HTTP function.

// functions/src/scheduledDigest.ts
import { onRequest } from "firebase-functions/v2/https";
export const scheduledDigest = onRequest(async (req, res) => {
  if (req.get("x-cron-secret") !== process.env.CRON_SECRET) {
    res.status(401).send("Unauthorized");
    return;
  }
  await runDigestForWorkspace(req.body.workspaceId);
  res.json({ ok: true });
});

Example: customer-specific recurring syncs

Suppose every connected account in your app can enable a sync every 30 minutes. When the account is connected, your backend creates a schedule instead of editing infrastructure config or maintaining a scheduler worker.

curl -X POST https://api.croncoco.io/jobs \
  -H "Authorization: Bearer coco_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"merchant-sync","cron_expression":"*/30 * * * *","webhook_url":"https://us-central1-your-app.cloudfunctions.net/scheduledDigest","headers":{"x-cron-secret":"YOUR_SECRET"},"payload":{"workspaceId":"ws_123"}}'

Now the schedule belongs to the account record in Firestore or your relational store. Your app can disable it when the customer disconnects, update it when preferences change, and inspect execution history when support needs answers.

Why this fits Firebase better

Firebase works best when backend paths stay small, event-driven, and stateless. An external scheduler calling a protected HTTP function keeps recurring work aligned with that model.

It also prevents the common drift from “we just need cron” into “we accidentally built a scheduler, retry queue, and audit system.”

When CronCoco is the better fit

CronCoco is useful when your Firebase app needs API-created recurring webhooks rather than a few fixed cron lines. If schedules are customer-owned, tenant-specific, or frequently updated from the product, CronCoco gives you the right boundary: your app decides what should run, CronCoco decides when to call it.

For related patterns, see serverless cron jobs, multi-tenant cron jobs, and how to schedule API calls. For the request shape and fields, start with the Create job docs.