Run functions from events and schedules
Configure reliable background, event, and scheduled function runs.
Last updated 2026-08-31
What you'll achieve
- Choose a supported runtime
- Understand execution and dependency limits
- Operate functions without exposing provider credentials
Trigger types
- HTTP request: runs when your published function route receives a request.
- Event: queues a run when you or an authorized automation submits a named event through the authenticated API or CLI.
- Schedule: queues a run at a fixed interval from one minute to 30 days.
- Background job: queues work that does not need to keep a browser request open.
Event, schedule, and background triggers are in beta. Create and manage them from a module's Triggers and runs panel or with blinkhost functions.
Delivery and retries
Asynchronous functions use at-least-once delivery. A run may be retried after a timeout or temporary platform failure, so handlers must be idempotent. Pass a stable Idempotency-Key when the same request might be sent again. BlinkHost binds every queued run to the exact verified artifact that was active when it was accepted; a replaced or revoked artifact is never silently substituted.
Each run has a durable state: queued, running, retrying, succeeded, dead lettered, or cancelled. Retry attempts are bounded from one to ten. Cancellation stops queued work immediately and requests cancellation of running work, but it cannot undo side effects already completed by your code.
Payloads, results, limits, and retention
Payloads and results are stored privately, scoped to the workspace, integrity checked, and never exposed through provider credentials. Payloads are limited to 256 KiB and results to 1 MiB. Runs use the same 30-second execution boundary and runtime capability policy as HTTP functions. Successful results are available through the dashboard and API. Payloads, results, and completed run records are deleted after the configured retention period, currently seven days.
Runtime use counts toward the workspace's function allowance. When an in-flight run crosses an allowance, its observed use remains recorded and later work is stopped under the normal plan controls.
CLI examples
blinkhost functions triggers list MODULE_ID
blinkhost functions triggers create MODULE_ID --data @trigger.json
blinkhost functions invoke run MODULE_ID TRIGGER_ID --data @payload.json --idempotency-key order-1042
blinkhost functions invocations list MODULE_ID
blinkhost functions invocations result MODULE_ID INVOCATION_ID
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.