Cron jobs
Invoke a Function on a schedule by adding a schedule expression to its entry in gigadrive.yaml.
Diese Seite ist ein Entwurf
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.
Schedules do not fire yet
The config file accepts the following rate(...) and cron(...) forms. The scheduler evaluates a plain five or six
field UTC cron instead, and nothing translates between the two, so a schedule declared today is registered but never
matches a minute. The mechanism exists, but it is not a feature you can ship against. Trigger recurring work from an
external scheduler until Gigadrive Network announces schedule support.
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.jsThe config file accepts two forms:
| Form | Example |
|---|---|
| A fixed interval | rate(1 hour), rate(5 minutes), rate(2 days) |
| A six field cron expression | cron(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. scheduledoes not inherit across patterns. When twofunctionspatterns match the same file, scalar settings such asmemorymerge with the later one winning, butscheduleis 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.
