Compute
Intermediate 11 min read Compute

Scheduled and Event-Driven Compute

Work that runs because of time or events

Not all compute runs on demand. Scheduled compute (cron in the cloud), event-driven trigger patterns, and instance scheduling save money and remove manual 'run the job' ops work.

scheduled computecronevent-drivenCloud SchedulerEventBridgetriggers
Prerequisites: Autoscaling
Before we start

What you will learn

  • Explain scheduled vs event-driven compute
  • Use Scheduler/EventBridge/Trigger to start work
  • Design idempotent scheduled jobs
In 60 seconds

Cloud schedulers fire on cron (Cloud Scheduler, Azure Scheduler-like triggers) and event bus triggers react to resource changes (EventBridge, CloudEvents). The compute they start — VM, container, function — should be idempotent and bounded.

Introduction

What is this?

Time-triggered: AWS EventBridge Scheduler, Azure Logic Apps/Scheduler triggers, GCP Cloud Scheduler (cron on UTC). Event-triggered: EventBridge CloudTrail/Service events, Azure Event Grid, GCP Pub/Sub → Cloud Functions/Workflows. Compute options ranged from stopping instances off-hours (a schedule) to rebuilding indexes when a file is dropped (an event). Also start/stop instance schedules to kill idle VM spend.

Motivation

Why do you need it?

  • Schedules make humans optional for recurring chores (backups, report gen, dusk starts).
  • Event triggers react in milliseconds vs polling minute-level crons.
  • Stopping dev instances off-hours is a free 60-70% compute saving.
  • Distributed triggers decouple producers from consumers cleanly.
Think about it

Mental model

Imagine

Alarm clock vs answering a phone call

Think of

Scheduled vs event-driven compute

An alarm fires at a set time (schedule) whether or not anything's happening outside; the phone rings precisely when someone calls (event) — you react to what actually arrived.

Mechanics

How it works

  • Scheduler: cron expression → message to a compute target (invoke function, run task, emit event).
  • Cloud Scheduler/EventBridge hold timezone, retry and dead-letter config per schedule.
  • Event bus: resources emit events (object create, instance state change, commit) that rules route to targets.
  • EventGrid/PubSub deliver with at-least-once semantics → consumers must be idempotent.
  • Instance schedules (AWS Instance Scheduler, Azure Auto-shutdown, GCP Cron stop) implement off-hour stop/start.

Time and event triggers.

Cron fires
Invoke target
Run idempotently
Event arrives
Route + react
Hands-on

Examples

Schedule and event triggers

Schedule and event triggers
# GCP: run a job at 2am UTC every day
gcloud scheduler jobs create http nightly --schedule="0 2 * * *" \
  --uri=https://us-central1-myproj.cloudfunctions.net/nightly \
  --time-zone=UTC
# AWS: react to an S3 object creation
aws events put-rule --name on-upload --event-pattern \
  '{"source":["aws.s3"],"detail-type":["Object Created"]}' \
  --schedule-expression "rate(5 minutes)"

Time-based jobs and event-driven jobs are configured declaratively and invoke compute automatically.

Real world

In production

  • Nightly log-archive job runs 1am via Cloud Scheduler, purging 30-day logs and refreshing a dashboard.
  • An object-creation event triggers a thumbnail ECS task when designers upload to the bucket.
  • AWS Instance Scheduler stops 200 non-prod instances at 7pm and starts them 8am, saving most of the estate's dev bill.
Guidelines

Best practices

  • Make scheduled jobs idempotent: a late run must not duplicate effects.
  • Give every schedule a timezone (UTC) and a retry policy with DLQ.
  • Watch event semantics: at-least-once means dedupe with object ids/keys.
  • Put scheduled compute behind a budget alarm so a runaway cron bills loudly early.
Watch out

Common mistakes

  • Timezone confusion: a '9am' job fires at 9am UTC, not local.
  • Non-idempotent jobs double-run after a retry (backups overwrite or duplicate).
  • Polling instead of events: 60/s polls burning compute while events would react instantly.
  • Forgetting to stop instance schedules in the same timezone/region — in-flight confusion.
Root cause analysis

Common issues

Error
Nightly job ran twice
Root cause

Retry + non-idempotent logic

Fix

Guard the job with a dedup key (run date), and make the payload a no-op when already executed.

Error
Off-hour stop didn't fire
Root cause

Scheduler timezone vs instance region mismatch

Fix

Standardize all schedules to UTC and apply stop/start in the instance's region.

When things break

Debugging tips

  • Watch scheduler logs for 'triggered but target failed', not just target errors.
  • Dead-letter queues capture events the rule couldn't route — check them first.
  • For off-hour stop/start issues, verify the schedule matches the instance timezone and the region's utc offset.
  • Add an execution-timestamp tag to scheduled jobs so a rerun is detectable.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

Why must event-driven consumers be idempotent?

Go deeper

Official documentation

AWS — EventBridge Scheduler
docs
Azure — Logic Apps triggers
docs
GCP — Cloud Scheduler
docs