Cloudflare Scheduled Workers
You set up cloudflare scheduled workers by adding cron triggers to your script settings. You then write a scheduled event handler in your code to run tasks on time. Most teams use this setup to run background jobs without managing their own servers. They store database keys and API tokens as worker secrets for these jobs. Still, broad permissions on those stored keys create risk when a task runs bad queries. If a script breaks or gets changed, it has full power over your backend data. How clou
Scheduled Workers: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloudflare scheduled workers by adding cron triggers to your script settings. You then write a scheduled event handler in your code to run tasks on time. Most teams use this setup to run background jobs without managing their own servers. They store database keys and API tokens as worker secrets for these jobs. Still, broad permissions on those stored keys create risk when a task runs bad queries. If a script breaks or gets changed, it has full power over your backend data.
How cloudflare scheduled workers run background jobs
A normal edge worker waits for a web request from a user to start running. A scheduled worker starts on a timer that you define with standard cron syntax. The edge platform reads your schedule and fires a trigger event at the right time. Your script catches this event and runs the task in the background.
Teams use this flow to clean up old data, send daily reports, or sync records. You can define multiple schedules for one worker to run different tasks at different hours. The handler checks which cron rule fired the event and picks the right logic. Your worker also uses an execution context method to stay alive until slow tasks finish. This ensures the platform does not shut down the script before a database write completes.
How teams manage worker secrets and permissions
Background jobs often need to read or write data in external databases and internal APIs. To do this, developers attach secret keys and database URLs to the worker settings. The platform encrypts these secrets at rest and passes them into the script at runtime. Team members need account roles to change the schedule or update the secret values.
Once the worker starts, it uses those static credentials to log in to your backend. Most teams give the worker a single role that covers every task it might run. The script holds these broad permissions for every scheduled run around the clock. Developers also test these scheduled handlers in a local setup before pushing code live. Local tests often use shared staging keys that live on developer laptops.
Scheduled Workers: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cron setups solve and where gaps remain
Native cron triggers solve the problem of running servers just for simple timed scripts. You do not need to patch Linux boxes or monitor a local cron daemon anymore. The platform handles the timer and runs your code on the global edge network. Account roles also control which developers can deploy code or edit the timer settings.
Still, the native setup only controls who can deploy the worker and set the timer. It does not inspect what the worker actually does inside your database during a run. Once the worker logs in with its secret key, every SQL statement runs unchecked. If a query returns sensitive fields like emails or card numbers, the script gets everything. Masking that rewrites matched fields in results is missing from standard database roles. Teams also lack a clear audit log of each individual query the background job ran.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do I run different tasks at different times in one worker?
You can attach several cron rules to a single worker in your project settings. Inside your scheduled handler, check the cron property on the event to route the logic.
Why did my scheduled task stop before finishing its database write?
The platform stops the worker as soon as the main handler function returns a result. You must pass your async task into the wait until method on the context object.
What happens when a scheduled worker reads sensitive user data?
By default, the database returns raw data for every field the worker role can read. To protect emails or phone numbers, you need data masking that rewrites fields in results.