$crond.io
integrations / google cloud

Google Cloud Scheduled Task Monitoring

GCP's scheduling surfaces — Cloud Scheduler, Cloud Run jobs, GKE CronJobs, GCE crontabs — all integrate with crond.io via HTTP pings or the agent wrapper.

Cloud Scheduler → HTTP target

The most common GCP pattern: Cloud Scheduler fires an HTTP request to your service at the scheduled time. Your service does its work and pings crond.io on success:

# Inside your HTTP handler (Node.js example)
app.post('/cron/nightly-job', async (req, res) => {
await doNightlyWork();
await fetch(`https://api.crond.io/ping/${process.env.CROND_KEY}`);
res.sendStatus(200);
});

For Cloud Scheduler jobs that target Pub/Sub instead of HTTP, the subscriber should ping after processing the message.

Cloud Run jobs

Cloud Run jobs run a container to completion. Bake crond-agent into the image and use it as the entrypoint:

# Dockerfile
FROM python:3.12-slim
RUN apt-get update && apt-get install -y curl && \
curl -sSL crond.io/install | sh
COPY job.py /app/
ENTRYPOINT ["crond-agent", "wrap", "--name", "daily-export", "--"]
CMD ["python", "/app/job.py"]

Pass CROND_PING_KEY as a Cloud Run job env variable (preferably from Secret Manager). The agent captures exit code and runtime — useful when Cloud Run logs scroll past.

GKE CronJobs

For GKE, the same patterns from our Kubernetes integration apply directly — the crond-monitor Helm chart works on GKE clusters without modification.

GCE crontabs

Traditional Linux crontab on a Compute Engine instance — install the agent and wrap:

curl -sSL crond.io/install | sh
# crontab -e
0 3 * * * crond-agent wrap --name "log-rotation" -- /usr/sbin/logrotate /etc/logrotate.conf

VPC and firewall

Cloud Run jobs and GCE instances need outbound HTTPS to api.crond.io:

  • Default GCP egress works — no special config needed in most projects
  • If you use Serverless VPC connectors with restricted egress, add a route for outbound 443
  • Cloud Armor / firewall rules on your origin services don't affect outbound pings

Cloud Scheduler doesn't retry on missed runs

A subtle GCP behavior worth knowing: if Cloud Scheduler can't reach its target (HTTP 5xx, timeout, deleted endpoint), it retries with exponential backoff within the schedule window — but if the issue persists, the missed run is lost. This is exactly the silent failure crond.io catches: even if Cloud Scheduler thinks it tried, the missing ping triggers an alert.

$get-started --free$cli reference