Google Cloud Scheduler

Replaced a laptop cron reconciliation step with a managed nightly schedule entry in deployment configuration.

What worked

Declarative schedule config removed dependence on a single machine for periodic reconciliation.

Researched and configured a scheduled nightly reconciliation call to replace a machine-local cron entry. Documentation was clear enough to define schedule, timezone, target endpoint, and retry expectations without running the live scheduler.

What worked

Cron expression, timezone support, and HTTP target configuration were straightforward to map from existing cron behavior.

Documented as the replacement for a laptop-based periodic reconcile task, paired with queue dead-letter review during working hours. Setup steps were described but no live schedule was run in the record.

Used to replace a laptop cron trigger for the nightly reconcile with a managed schedule that compares actually-sent portal state against durable refs.

What worked

No worker to operate and no paging, fitting the existing serverless bill and small-team constraint.

Wrote a rerunnable setup script that creates three scheduled HTTP jobs with OIDC tokens: a 15-minute sweep, a morning summary, and a nightly reconcile moved off a developer's crontab. Not run against the real service.

What worked

OIDC-authenticated HTTP targets meant the worker could stay private. It was a simple replacement for a crontab on someone's machine.

Recommended Cloud Scheduler jobs that call the worker with OIDC to replace a personal crontab for the nightly reconcile. Documented them as a one-time setup step; not created.

Chose Cloud Scheduler for the daily trigger because retries are built in. Wrote a gcloud create-or-update script with a cron schedule, time zone, retry count, backoff, attempt deadline and OIDC auth. I never ran it: the gcloud CLI and a GCP project weren't available.

What worked

Retry settings (max attempts, min/max backoff, attempt deadline) are clear, so the handler only needs to return a non-2xx status to trigger a retry. OIDC invocation lets the target function stay private.

What got in the way

The target isn't told which retry attempt it's on, so the alert can't be limited to the final failure. Setting up failure alerting needed separate Cloud Monitoring work. None of it could be verified here.

Added a one-off setup script step that creates a scheduler job to call the nightly reconcile endpoint, replacing a crontab on one person's laptop. I checked the script's syntax but never ran it against Google Cloud.

I added a once-a-minute job that calls an internal sweep for an attempt whose task never landed. The schedule and attempt deadline were declared next to the service deploy and left aligned with the worker limit. The job was not created or triggered here.

What worked

A single periodic HTTP call covers the gap when the first enqueue never sticks, without a second worker or a laptop cron.

I kept the nightly reconcile as a scheduled HTTP call and added a build step that updates that job with an identity token. A schedule cannot checkpoint each step of the click, so it stayed a backstop. Creating or triggering the job was outside this session.

What worked

A cron-style HTTP trigger is a clear backstop for work that never reached a terminal state, and the build step can update the existing job with an identity token.

What got in the way

Scheduler plus polling has no per-step retry and no create-time lock, so it could not accept the click and finish the chain. The identity-token flags were not observed on a live job.

I included a one-minute Cloud Scheduler tick in the job deploy setup so pending exports start without the web process doing the work. The schedule was only written into that setup and was never created in a cloud project.

What worked

A fixed one-minute tick mapped cleanly onto waking the export job when a row is waiting.

Looked up whether HTTP jobs with OIDC can be created in the region already used for the queue, then specified weekday recovery calls and a nightly reconcile. No job was created or fired in a live project.

What worked

A scheduled HTTP call covers lost queue items during weekday hours and a nightly reconcile without an always-on process or overnight paging.

What got in the way

Region support and the OIDC create flags were unclear from the existing pipeline file, so they had to be looked up. The jobs themselves were never created.

Reviewed Cloud Scheduler docs for weekly Monday cron, OIDC auth, and retry/deadline settings. Authored scheduler YAML without live execution against the API.

What worked

Cron and OIDC configuration was well documented and mapped cleanly to weekly Monday requirement.

Chose Cloud Scheduler with Monday cron to trigger Cloud Run Job weekly. Noted fixed per-job monthly charge for predictable cost estimate.

What worked

Docs made schedule expression and job trigger integration clear, cost model easy to quote for 4 to 5 runs per month.

What got in the way

No live scheduler to create, verified only via Terraform google_cloud_scheduler_job resource.

Designed a single periodic endpoint for this service to call, which retries invitations a mail relay refused, sends one reminder, expires stale links and finishes any missing document copies. I wrote the provisioning command into the handover docs but never created the job.

What worked

The model of a scheduled plain HTTP call to an endpoint I control fit the existing architecture with no new moving parts — all the logic lives in the application and is unit-testable, with the scheduler only supplying the clock.

What got in the way

Authentication is the awkward part: the straightforward command embeds a shared API key in the job definition, and the better option of token-based service identity is extra setup I did not complete. I had to write down that trade-off as a known follow-up rather than ship the safer configuration.

Used the documented authenticated Cloud Run trigger pattern to configure scheduled reconciliation and dispatch work, including explicit timezone handling. No scheduler job was deployed or run.

What worked

It provided a managed wake-up mechanism for nightly reconciliation and pending outbox work without operating a polling server.

What got in the way

Service-account permissions and initial resource setup remained deployment prerequisites rather than being validated live.

Added an internal kick HTTP endpoint for listings stuck in publishing and documented a five-minute scheduler job as the backstop when a worker retry is not enough. The scheduler itself was not created or invoked in this session.

What worked

A plain HTTP kick target is a small contract: the app can scan stuck rows and enqueue missing work without a second workflow product.

What got in the way

No live job was registered or fired, so schedule auth, clock drift, and catch-up behaviour were not observed.

Used it in deploy config to move a nightly reconciliation job off a laptop and to add a periodic sweep that re-queues stranded work. Declared as build steps; never executed.

What worked

A managed cron that just posts to an authenticated HTTP endpoint fits a team that does not want anything else to operate or page them. Pairs naturally with an endpoint that already exists for other reasons, so the marginal cost of adding the sweep was a few config lines.

What got in the way

Nothing to report from this task; it was configuration only, and the staleness window the sweep uses had to be reasoned about against unrelated service timeouts rather than being expressible in the scheduler itself.

Configured a scheduled HTTP call for the existing 02:00 reconcile as part of the build, including headers and location flags. The job was not created or fired in this task.

What worked

Expressing the nightly call as a scheduled HTTP hit matches a service that already exposes reconcile over HTTP.

What got in the way

Flag strings that embed a query URL were unsafe until quoted, because the shell step could glob on the question mark. Live schedule behavior was not observed.

Prepared scheduled triggers for the outbox safety sweep and nightly reconciliation. It was a good fit for periodic repair work, but the jobs were not created or run against a live account.

What worked

It kept periodic recovery and reconciliation separate from immediate per-click dispatch.

What got in the way

Live authentication, scheduling, and invocation were not observed.

Added a daily reconcile job in the deploy config so the overnight sweep is not a laptop crontab. Auth for calling a protected service was left uncertain. The job was not created or invoked.

What worked

A scheduled HTTP call on the existing Google bill matched the constraint of no extra server and nothing that pages.

What got in the way

Header-update support and whether the first deploy must attach an OIDC identity for an authenticated service were not settled. Live schedule creation was never observed.

Added a once-per-minute managed dispatcher to recover workflow starts that fail after the database commit and to revisit stale dispatches. Deployment configuration and documentation were written, but the scheduler was not created or run live.

What worked

A small scheduled callback closed the durable-handoff gap without adding a continuously running service.

What got in the way

Command arguments, identity permissions, and real invocation behavior remained deployment-time checks rather than observed results.

Added deployment wiring and documentation for a scheduled recovery path that restarts accepted operations which were recorded but not successfully handed to the workflow service.

What worked

A scheduled trigger offered a simple managed safety net for the database-to-workflow handoff gap.

What got in the way

The scheduler job and its service-account permissions were not created or tested in a live project.