Use case
Trigger Cloud Run on a cron, skip the Cloud Scheduler IAM dance.
Cloud Scheduler is a fine product if you are already deep in GCP. It is also per-project, per-target IAM, and $0.10 per job per month after the first 3. If you have 20 Cloud Run endpoints to trigger, Crontap is faster to set up and cheaper to run.
Free plan · no credit card required
The problem
Why this is painful without the right tool
- Cloud Scheduler needs an OIDC token wired up for every Cloud Run target, plus a service account, plus an IAM binding per route.
- After the first 3 free jobs per billing account, Cloud Scheduler bills $0.10 per job per month, which compounds across a multi-project org.
- A multi-project GCP setup ends up with several Scheduler consoles and no central view across projects.
- Cloud Logging is the only failure surface; rich alerting to email or webhook is left for you to wire up separately.
The fix
How Crontap solves it
Paste your Cloud Run URL. Paste the Authorization header (if you chose to lock the URL). Pick a cron. You are done in 60 seconds. No IAM bindings, no OIDC wiring, no per-target service accounts.
0 15 * * *One concrete pattern from the dataset: a Cloud Run team running daily AWS SES reports and 9-hour domain monitors against a single *.run.app service. Three task endpoints, three schedules, three different cadences: task/email-validator-credit-check daily at 08:00, task/domain-monitor every 9 hours, and task/ses-daily-report daily at 15:00 in America/Bogota. Each schedule lives next to the others in one dashboard, fires on the team's local time, and alerts to email / webhook (Slack / Discord / Telegram) on 5xx.
For securing the URL, two patterns work. Either deploy with --no-allow-unauthenticated and route through a small intermediate that verifies a shared secret, or keep --allow-unauthenticated and check a bearer header Crontap sends on every run. Most teams pick the second; it is one line in the handler.
For the head-to-head decision frame and a migration playbook from Cloud Scheduler, see Crontap vs Google Cloud Scheduler.
FAQ
Common questions
- How do I secure the Cloud Run URL?
- Either deploy with --no-allow-unauthenticated and route via an intermediate with a shared secret, or keep --allow-unauthenticated and check a bearer header Crontap sends on every run. Most teams take the second path because it is one line in the handler.
- Is this allowed by Google?
- Yes. Cloud Run URLs are public HTTPS endpoints by design; anyone can call them, and the auth check is your responsibility regardless of who triggers the call. Crontap is just an HTTPS client that fires on a schedule.
- Can I still use Cloud Scheduler for things where IAM is mandatory?
- Yes. Mix freely. Keep Cloud Scheduler for IAM-bound jobs, Pub/Sub triggers, or anything your security policy requires to stay GCP-native; add Crontap for everything else and consolidate the dashboard.
Related guides
Adjacent use cases
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