Comparison
Crontap vs Firebase Scheduled Functions
Firebase Scheduled Functions are a thin convenience layer over Cloud Scheduler and Pub/Sub — both billed Google Cloud products that require the Blaze plan. Crontap is an external HTTP cron that calls your function URL on the schedule you set. Works on Spark, no billing upgrade, and the schedule layer is portable across non-Firebase code paths.
At a glance
Firebase Scheduled Functions vs Crontap, side by side.
| Dimension | Firebase Scheduled Functions | Crontap |
|---|---|---|
| Works on Firebase Spark plan | No (Blaze required) | Yes (external) |
| Triggers your function on a cron | Yes (via Cloud Scheduler + Pub/Sub) | Yes (direct HTTPS) |
| Per-IANA timezone per schedule | Yes (Cloud Scheduler) | Yes |
| Automatic retries on failure | Cloud Scheduler retry config | Yes (5xx with backoff) |
| Per-run logs + response body | Cloud Logging (Cloud Functions) | Yes (Crontap dashboard) |
| 1-minute cadence | Yes (1-min minimum on Cloud Scheduler) | Yes (Pro plan) |
| Failure alert routing | Cloud Logging + Alerting (manual setup) | Email, Slack, Discord, Telegram out of the box |
| Cross-platform cron (non-Firebase targets) | No (Firebase-only) | Yes (any HTTP endpoint) |
| Starting paid | Blaze (pay-as-you-go, no hard cap) | $3.25/mo annual flat |
How they work
The two approaches in one paragraph each.
Firebase Scheduled Functions
Firebase Scheduled Functions are syntactic sugar over three Google Cloud services glued together: the function itself runs on Cloud Functions, a Cloud Scheduler job (created by the firebase CLI) fires on the cadence in your code, and a Pub/Sub topic delivers the trigger. The Firebase CLI rejects deploys on the Spark plan because Cloud Scheduler and Pub/Sub are billed Google Cloud products and Spark does not include billed services.
Crontap
Crontap is external HTTP cron — a scheduler that hits a URL you expose. You keep Firebase on Spark for everything you're already using (Firestore, Auth, Hosting, Storage), and you host the scheduled work behind any HTTPS endpoint Crontap can reach. Crontap fires the request on the cadence you set, retries 5xx, and emails when a run fails.
Where each side wins
Honest broker, both columns.
Firebase Scheduled Functions wins on
- Single-vendor experience: schedule, function, logs, and billing all in the Firebase / Google Cloud Console.
- Native Cloud Logging integration for both the Scheduler job and the function.
- Pub/Sub fan-out: one trigger can publish to multiple subscribers if your architecture is event-bus shaped.
- Cloud Scheduler's retry semantics are configurable per job.
Crontap wins on
- Works on the Firebase Spark plan — no billing upgrade for one or two scheduled jobs.
- No Cloud Scheduler + Pub/Sub setup; the schedule is one URL and one cron expression.
- Flat $3.25/mo annual on Pro vs Blaze's pay-as-you-go surface (no soft cap to monitor).
- Failure alerts to email / Slack / Discord / Telegram out of the box; no Cloud Logging + Alerting policy chain.
- Schedules are portable: the same Crontap account can fire a Cloud Run service, a Render endpoint, or a Lambda Function URL on the next line down.
- Cadence changes are dashboard saves, not Firebase CLI deploys.
The math
Cadence and pricing, worked out.
- Firebase Scheduled Functions require Blaze. Blaze is pay-as-you-go: Cloud Functions itself has a generous free tier, but Cloud Scheduler costs $0.10 per job per month after the first 3, and Pub/Sub is metered on messages and bandwidth. For 5+ scheduled jobs the surface starts to show up on the bill.
- Crontap Pro is $3.25/mo annual flat for unlimited HTTP schedules at minute cadence. The Firebase project itself stays on Spark.
- For indie projects, workshops, and cost-sensitive teams who specifically chose Spark for its hard cap, an external HTTP scheduler avoids both the plan migration and the unbounded billing surface.
Moving from Firebase Scheduled Functions
The migration, in 6 steps.
- Refactor each `functions.pubsub.schedule(...)` function so its body lives in a function you can call from an HTTPS handler.
- Add an HTTPS endpoint (Cloud Run, a small backend, a Vercel API route — whatever you already deploy) that authenticates a bearer token and calls the refactored function.
- Create a Crontap schedule against that URL using the same cron expression. Set the same IANA timezone.
- Verify the Crontap run log matches the old Cloud Logging entries for one full cycle (24 hours for a daily job, an hour for a per-minute job).
- Delete the `functions.pubsub.schedule(...)` declaration and `firebase deploy --only functions`. The Cloud Scheduler job and Pub/Sub topic the CLI created get cleaned up.
- Stay on Spark.
Decision
Which one fits.
Pick Firebase Scheduled Functions if
You're already on Blaze, you're invested in Cloud Logging + Pub/Sub, and you want the Scheduler config inside the Firebase Console next to everything else.
Pick Crontap if
You're on Spark and don't want to migrate billing for a small number of scheduled jobs, or you want failure alerts that aren't a Cloud Logging policy chain.
Pair both if
Use Cloud Scheduler for jobs that are genuinely Firebase-internal (Pub/Sub fan-out). Use Crontap for HTTP cron that fires anything reachable, Firebase or not.
FAQ
Crontap vs Firebase Scheduled Functions, in detail.
- Why does Firebase require Blaze just to schedule a function?
- Because Scheduled Functions are built on Cloud Scheduler and Pub/Sub, both of which are billed Google Cloud products outside the Spark plan's product set. There's no Spark-side toggle that turns them on. The Firebase CLI refuses the deploy because the underlying services would fail to create.
- Can Crontap call a Firebase Cloud Function directly?
- Yes, if the function is HTTP-triggered (`onRequest` in v1 or the new v2 HTTPS trigger). Crontap calls the function URL with a bearer header on the cadence you set. You stay on Spark; the function still runs on Cloud Functions, but the schedule layer lives outside Firebase.
- What about authentication?
- Store a long random secret in Crontap's per-schedule Authorization header. Verify it in your handler before doing any work. The function URL stays public-by-DNS but every request is checked against the secret. See the Firebase Scheduled Functions without Blaze post for the exact code shape.
- Will I lose anything by moving the schedule outside Firebase?
- The biggest tradeoff is that the schedule no longer shows up in the Firebase Console. You see it in the Crontap dashboard instead. Cloud Logging still records every function invocation; you just have one extra dashboard for the clock layer.
Sources
Ready to fix it?
Point Crontap at any URL. Pick any cron. Done.
WordPress, Shopify, Railway, Cloud Run, Vercel, HubSpot, Ghost, your own box. If it answers HTTP, Crontap can drive it on a clock you can read, in the timezone that actually matters, and page you when something breaks.
Free forever tier ・ No credit card required
/wp-cron.php?doing_wp_cron=1
Schedule
"every 5 minutes"
Next
in 23s