Use case
Trigger Cloud Run from one cross-cloud schedule view.
Cloud Scheduler is a strong GCP-native product with methods, headers, payloads, timezones, and configurable retries. Authenticated Cloud Run targets use OIDC, while public HTTP targets do not inherently require it. Crontap fits when HTTP routing, alerts, uptime, and heartbeats should span clouds.
Free plan · no credit card required
The problem
Why this is painful without the right tool
- Authenticated Cloud Run invocation needs a service account and OIDC; a public HTTP target can use application-level authentication instead.
- 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 Monitoring alerts require metrics and alert-policy setup rather than direct per-job chat routing.
The fix
How Crontap solves it
Paste a publicly reachable Cloud Run URL, add the application-level Authorization header your handler checks, and pick a cron. For an IAM-private Cloud Run service, keep Cloud Scheduler or route through a public authenticated proxy.
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, retries failed requests, and alerts to connected email, Slack, Discord, or Telegram channels, plus machine webhook Integrations if the final attempt remains 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.
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