Zum Inhalt springen
GigadriveDocs

Cron jobs

Invoke a Function on a schedule by adding a schedule expression to its entry in gigadrive.yaml.

A Function can be invoked on a schedule without any client calling it, by adding schedule to its entry in gigadrive.yaml. Gigadrive Network then sends it a request on the cadence you declare.

Declaring a schedule

version: 4

functions:
  api/cleanup.js:
    runtime: node-22
    memory: 256
    max_duration: 300
    schedule: rate(1 hour)

routes:
  - source: ^/cleanup$
    destination: /api/cleanup.js

The config file accepts two forms:

FormExample
A fixed intervalrate(1 hour), rate(5 minutes), rate(2 days)
A six field cron expressioncron(0 12 * * ? *)

Three rules decide whether a schedule is registered at all:

  • One schedule per Function. Redeploying replaces it rather than adding a second.
  • The Function needs a public route. The schedule targets the Function's / route when it declares one, otherwise its first declared route. A Function reachable at no path is skipped silently.
  • schedule does not inherit across patterns. When two functions patterns match the same file, scalar settings such as memory merge with the later one winning, but schedule is read only from the pattern that first produced the Function. Declare it on the pattern that owns the file, never on a broad glob you expect to be overridden.

What the platform sends

The request goes to the deployment's own hostname at the Function's route path, over the public edge. It takes the same path a browser request takes, which means routing, waking a Function that has scaled to zero, logging and billing all behave identically.

  • The method is GET, and no body is sent. Neither is configurable.
  • Your Function receives x-nebula-cron: true. No client on the internet can set that header, so you can trust it to tell a scheduled invocation apart from ordinary traffic.
  • The request is abandoned if your Function has not responded within 30 seconds.

What is not guaranteed

Schedules are evaluated once a minute in UTC. A schedule cannot run more often than that, and the exact second within the matching minute is not fixed.

Delivery is judged by the response status. Only a 2xx counts as delivered; anything else, including a timeout or a connection failure, leaves the schedule unmarked so the next evaluation retries it. A Function returning 500 will therefore be called again a minute later, repeatedly, until it succeeds or the matching window passes.

Exactly-once delivery is not offered. Make the endpoint idempotent, and do not use the request itself to carry state.