Comparison
Crontap vs Google Cloud Scheduler
Cloud Scheduler is a fine GCP-native product if your scheduling needs are modest and your team already does IAM. Once you cross 3 jobs or work across multiple projects, the bill grows and the IAM glue grows faster.
At a glance
Google Cloud Scheduler vs Crontap, side by side.
| Dimension | Google Cloud Scheduler | Crontap |
|---|---|---|
| Cadence minimum | 1 minute | 1 minute (Pro) |
| Free tier | 3 jobs free per billing account | free tier available |
| Per-job cost above free | $0.10 per job / month | Flat plan price |
| Cross-project view | Per-project Scheduler console | All projects + non-GCP targets |
| Auth setup per target | OIDC token + service account | Authorization header |
| Region binding | Regional | Global |
| Failure alerts | Cloud Logging only | email / webhook (Slack / Discord / Telegram) |
| Pricing | $0.10 per job/month after first 3 | $0 free / $3.25/mo Pro |
How they work
The two approaches in one paragraph each.
Google Cloud Scheduler
Cloud Scheduler is a managed scheduler that lives inside a GCP project. Each job pairs a target (HTTP, Pub/Sub, or App Engine) with a cron expression. HTTP targets need an OIDC token plus a service account with IAM bindings on the receiving service. Logs go to Cloud Logging, scoped to the project. The first 3 jobs per billing account are free; after that, $0.10 per job per month.
Crontap
Crontap is an external scheduler. You paste any HTTPS URL (Cloud Run, Cloud Functions, Lambda Function URL, your own box), set the cadence and timezone, and add an Authorization header if the target needs auth. Crontap fires the endpoint on cadence; nothing about the schedule is bound to a GCP project, region, or IAM policy.
Where each side wins
Honest broker, both columns.
Google Cloud Scheduler wins on
- Native to GCP, audited, IAM-aware.
- First 3 jobs free per billing account.
- Built into the Cloud Console next to Cloud Run and Pub/Sub.
- First-class with Cloud Run, Pub/Sub, App Engine.
Crontap wins on
- No OIDC or service account setup per target.
- Flat plan price beats $0.10 per job once you pass a handful.
- Single dashboard across all GCP projects, plus non-GCP targets like AWS Lambda Function URLs, Vercel, Railway, or your own box.
- Centralized failure alerts to email or webhook (Slack, Discord, Telegram) instead of just Cloud Logging.
The math
Cadence and pricing, worked out.
- 20 Cloud Scheduler jobs across 3 GCP projects: 17 chargeable jobs at $0.10/month equals $1.70 baseline, plus the time spent on OIDC and IAM setup per target. Crontap Pro is $3.25/month annual flat for unlimited schedules.
- Need an Authorization header on the target? In Cloud Scheduler, configure an OIDC token plus a service account with IAM bindings on the receiving service. In Crontap, paste the header on the schedule.
Moving from Google Cloud Scheduler
The migration, in 3 steps.
- List the Cloud Scheduler jobs and their target URLs. Note which run per project and which currently use IAM-bound auth.
- For each Cloud Run target, pick: keep `--no-allow-unauthenticated` and call via a thin internal proxy that verifies a shared secret Crontap sends, or enable `--allow-unauthenticated` and check a bearer header in your handler.
- Recreate each schedule in Crontap with the URL plus the Authorization header. Disable the corresponding Cloud Scheduler job once Crontap has run cleanly for one cadence.
Decision
Which one fits.
Pick Google Cloud Scheduler if
You have fewer than 3 jobs, you need IAM-bound auth on the target, or your security policy mandates GCP-native scheduling.
Pick Crontap if
You have several jobs, work across multiple GCP projects, or want a single dashboard with alerting beyond Cloud Logging.
Pair both if
Keep Cloud Scheduler for IAM-bound jobs and Pub/Sub triggers. Add Crontap for everything else, including jobs that span GCP projects or reach non-GCP targets.
FAQ
Crontap vs Google Cloud Scheduler, in detail.
- Does Crontap support OIDC?
- Not directly. Use a bearer token or shared secret verified in your code, or front the URL with a thin authenticated proxy that exchanges the bearer for an OIDC token before calling the inner service.
- Will this work with Cloud Run?
- Yes. Either keep `--no-allow-unauthenticated` and route through a thin internal proxy that verifies a shared secret Crontap sends, or enable `--allow-unauthenticated` and check a bearer header in your handler. The cron-jobs-for-cloud-run guide covers the wiring in detail.
- Can Crontap call private endpoints?
- Yes via Authorization headers. For VPC-bound endpoints, expose a public proxy that authenticates Crontap and forwards into the VPC. Crontap itself is HTTPS-only and does not run inside your VPC.
- Is this allowed by Google?
- Cloud Run URLs are public HTTPS endpoints by design, intended to be callable from any client that has the URL plus the configured auth. Calling them from an external scheduler is a normal deployment pattern.
- What about Pub/Sub triggers?
- Crontap is HTTP-only. For Pub/Sub-backed jobs, keep Cloud Scheduler as the trigger source. You can pair both: Cloud Scheduler for Pub/Sub triggers, Crontap for HTTPS targets.
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