Comparison
Crontap vs Firebase Scheduled Functions
Firebase Scheduled Functions are Blaze-only and create a Cloud Scheduler job plus an HTTP function. Crontap does not make Cloud Functions available on Spark. It can keep the Firebase data, Auth, or Hosting project on Spark only when the scheduled HTTP runtime is hosted somewhere else.
At a glance
Firebase Scheduled Functions vs Crontap, side by side.
| Dimension | Firebase Scheduled Functions | Crontap |
|---|---|---|
| Can keep the data/Auth project on Spark | No (Blaze required) | Yes, only with the HTTP runtime hosted elsewhere |
| Triggers your function on a cron | Yes (Cloud Scheduler invokes the HTTP function) | Yes (direct HTTPS) |
| Per-IANA timezone per schedule | Yes (Cloud Scheduler) | Yes |
| Per-run logs | Cloud Logging (Cloud Functions) | Status, code, duration, size, error summary |
| 1-minute cadence | Yes (1-min minimum on Cloud Scheduler) | Yes (Pro plan) |
| Cross-platform cron (non-Firebase targets) | No (Firebase-only) | Yes (any HTTP endpoint) |
| Starting paid | Blaze (pay-as-you-go, no hard cap) | from $2.99/mo |
| Free tier | Scheduled Functions are Blaze-only | Starter: 2 combined items; schedules hourly+, 1 uptime monitor daily, and 1 heartbeat hourly |
| Human Notifications | Cloud Logging and user-configured Cloud Monitoring alert policies | All plans: email, test sends, product defaults, per-item default/custom/off routing, and delivery history. Pro, Ultra, and legacy Pro add Slack, Discord, and Telegram |
| Machine webhook Integrations | Google Cloud event and monitoring integrations | Separate machine webhook Integrations with per-event success, failure, missed, and recovered levers where applicable |
| Schedule failure batching | Not compared; Crontap schedule-specific alert setting | Schedule alerts: unsaved default Starter 24h / 3 failures, paid 10m / 3; configurable floor Starter 1 day, paid 1 minute |
| Heartbeat / dead-man monitoring | No native dead-man monitor in Scheduled Functions | Native: period + grace, /fail, missed/recovered/explicit-failure alerts, ping URL, and 90-day history |
| Uptime monitoring | Cloud Monitoring requires separate setup | Native HTTP uptime: down/recovered alerts, history, 90-day rollups, and integration controls |
| Retries and customization | Strong configurable Cloud Scheduler retry policy | Default on: 3 retries with 2× exponential backoff and jitter. Pro, Ultra, and legacy Pro: 1–5 retries plus delay and retry outcomes; alert after exhaustion |
| AI response processing | No response transform-and-forward workflow | AI response transforms: transform, summarize, normalize, extract, or triage, then forward. Pro: daily, 1 per schedule. Ultra: hourly, unlimited; test-run UX |
How they work
The two approaches in one paragraph each.
Firebase Scheduled Functions
Firebase's onSchedule handler deploys an HTTP function and a Cloud Scheduler job. The default compute service account invokes the function. Scheduled Functions require Blaze, support cron or App Engine schedule syntax, and can overlap unless the function handles concurrency.
Crontap
Crontap calls a reachable HTTP endpoint. To keep a Firebase project on Spark, that target must run elsewhere, such as Render, Vercel, Cloudflare, or another backend, and use the Firebase APIs it is permitted to access. Crontap adds request configuration, retries, response processing, and monitoring around that endpoint.
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.
- Default compute service-account invocation of the associated HTTP function.
- Cloud Scheduler's retry semantics are configurable per job.
Crontap wins on
- Can leave Firebase data, Auth, or Hosting on Spark when the HTTP runtime is hosted elsewhere.
- No Cloud Scheduler setup for an already-public HTTP target.
- From $2.99/mo on Pro for the scheduling and monitoring layer.
- Direct human Notification routing plus separate machine webhook Integrations.
- 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.
- Alerts when the function never checked in through native heartbeats.
The math
Cadence and pricing, worked out.
- Firebase Scheduled Functions require Blaze. Each underlying Cloud Scheduler job is $0.10 per month after the three-job Google account allowance, while Function compute is billed separately.
- Crontap Pro starts at $2.99/mo, but an external runtime may also cost money. Do not compare Crontap's scheduler price to the full Firebase runtime as if they were equivalent products.
- Spark remains possible only for the Firebase services the project uses when the scheduled runtime is hosted and billed elsewhere.
Moving from Firebase Scheduled Functions
The migration, in 6 steps.
- Refactor each `onSchedule(...)` function so its body lives in a function you can call from an HTTPS handler.
- Add an HTTPS endpoint, such as Cloud Run, a small backend, or a Vercel API route, 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 `onSchedule(...)` declaration and deploy the change so Firebase cleans up the managed function and Cloud Scheduler job.
- Stay on Spark.
Decision
Which one fits.
Pick Firebase Scheduled Functions if
You're already on Blaze, you want the managed HTTP function plus Cloud Scheduler job, and Cloud Logging is your operational home.
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 Firebase Scheduled Functions for code that belongs in the Firebase deployment and Crontap for HTTP jobs that span other runtimes.
FAQ
Crontap vs Firebase Scheduled Functions, in detail.
- Why does Firebase require Blaze just to schedule a function?
- Because a Scheduled Function deploys billed Cloud Functions and Cloud Scheduler resources. Spark cannot host that scheduled function. Moving only the clock outside Firebase does not change the runtime requirement.
- Can Crontap call a Firebase Cloud Function directly?
- Yes, if the project is on Blaze and the HTTP function permits the request. Moving only the schedule to Crontap does not make Cloud Functions available on Spark. To remain on Spark, host the HTTP handler elsewhere and let it call the Firebase services your project uses.
- 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