Comparison
Crontap vs Google Cloud Scheduler
Google Cloud Scheduler is a capable managed scheduler with methods, headers, body, timezone support, and highly configurable retry behavior. Public HTTP targets do not always need OIDC; authenticated Google targets can use OIDC or OAuth. Crontap's wedge is simpler cross-cloud routing, human notifications, uptime, heartbeats, and response processing.
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 | Starter: 2 combined items; schedules hourly+, 1 uptime monitor daily, and 1 heartbeat hourly |
| 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 | Optional for public HTTP; OIDC/OAuth for authenticated targets | Authorization header |
| Region binding | Regional | Global |
| Pricing | $0.10 per job/month after first 3 | $0 free / from $2.99/mo Pro |
| Human Notifications | Cloud Monitoring alerts require metrics and alert-policy setup | 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 | Cloud Logging, Monitoring, Pub/Sub, and Google APIs | 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 | Native: period + grace, /fail, missed/recovered/explicit-failure alerts, ping URL, and 90-day history |
| Uptime monitoring | Available through separately configured Cloud Monitoring | Native HTTP uptime: down/recovered alerts, history, 90-day rollups, and integration controls |
| Retries and customization | Strong configurable exponential backoff: attempts/duration, min/max backoff, doublings | 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 built-in HTTP 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.
Google Cloud Scheduler
Cloud Scheduler pairs a cron or human-readable schedule with HTTP, Pub/Sub, or App Engine targets. HTTP jobs support methods, headers, body, timezone, and optional OIDC or OAuth authentication. Retry policy can tune attempts or duration, min/max backoff, and doublings. The first three jobs per billing account are free, then each job costs $0.10 per 31 days.
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.
- More extensive retry-policy controls than Crontap.
Crontap wins on
- Simple stored headers for public HTTP targets without adding a cloud project.
- Single dashboard across all GCP projects, plus non-GCP targets like AWS Lambda Function URLs, Vercel, Railway, or your own box.
- Starter includes email Notifications; Pro, Ultra, and legacy Pro add Slack, Discord, Telegram, shorter intervals, test sends, and delivery history.
- Native uptime and heartbeat monitoring, plus separate machine webhook Integrations.
The math
Cadence and pricing, worked out.
- 20 Cloud Scheduler jobs under one billing account mean 17 billable jobs, or $1.70 per 31 days. That is cheaper than Crontap Pro at $2.99/mo if price alone decides.
- Public HTTP targets can use headers and do not inherently require OIDC. Use OIDC or OAuth when the receiving Google service requires authenticated identity.
Moving from Google Cloud Scheduler
The migration, in 4 steps.
- Paste your existing config into the free cron migrator to get every schedule pre-filled as a Crontap deep link.
- 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 need Pub/Sub or App Engine targets, IAM-bound invocation, advanced retry controls, or the lowest per-job scheduler price.
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