Serverless scheduled tasks: where recurring jobs break
Serverless scheduled tasks look reliable right up until the first incident: the schedule fires, but the result never arrives.
The classic scenario — a job is triggered by a timer, the handler crashes halfway through, the platform considers the attempt complete, and the next run is a day away. No one gets paged, the "successful invocations" metric is green, and a day's worth of data is lost.
Missed runs are almost always the result of two causes: schedule overlaps and concurrency limits.
If the previous execution is still running while a new one is already queued, some triggers are dropped silently — especially when the schedule uses a frequent interval and the handler calls an external service with unpredictable latency.
Stuck executions look different: the function doesn't crash, it waits for a response from a database or queue, the timer fires, the platform forcibly terminates the process, and the transaction is left in an intermediate state.
Duplicates are the flip side of fault tolerance. The platform retries event delivery on a network failure or timeout, and without idempotency the job runs twice: charges, mailings, and exports go out at double volume.
Silent errors finish off the picture — an exception is swallowed inside the handler, the invocation status is successful, and the failure only becomes visible through indirect signs days later.
Let's break down how this gets addressed: idempotent run keys, separating the schedule from the queue, monitoring stuck executions by timeout, and a dedicated alerting channel for missed expected runs.
What managed scheduled job execution delivers
Predictable runs instead of "floating" timing
An EventBridge schedule fires on a cron expression with minute-level precision, not "whenever the server wakes up." For recurring tasks — exports, reconciliations, mailings, aggregate recalculations — this eliminates a whole class of problems: a run doesn't drift because of a machine reboot, queue overflow, or a stuck previous process.
If a task runs longer than its window, the next run doesn't overlap: concurrent instances are suppressed at the rule level. Start time stops being a matter of guesswork — it's the same on weekdays and at peak load.
Manual checks move into monitoring
Previously, the on-call engineer opened logs and eyeballed whether the nightly export had completed. Now the system reports it: a successful run writes a metric, an error triggers an alert to the team channel with the exception body and request ID.
The number of manual checks drops from daily walkthroughs to zero, and the engineer focuses on troubleshooting rather than watching.
We separately configure "dead" silence: if a task hasn't started within the expected window, a notification arrives — silence is also a signal.
Incident response time is minutes, not days
An incident is caught at the moment of failure, not in the morning when a user notices missing data. Retries with a delay cover short-term failures of external services without human involvement — most failures are suppressed automatically.
What couldn't be recovered arrives with context: how many attempts, at which step, what the external API returned. The investigation starts with facts, not with reproduction.
What this adds up to
Runs become predictable, manual control becomes redundant, and incident response is measured in minutes. The team stops keeping a task calendar in their heads and switches to product development.
Launch methods: scheduler, queue, manual trigger
Recurring tasks in a serverless environment are launched in three ways, and the choice between them is determined not by convenience but by the nature of the workload and the requirements for repeatability.
A scheduler (in AWS this is EventBridge Scheduler) invokes a function based on a cron or rate expression: it is good for tasks with a fixed time — nightly reports, directory synchronization, cache warming.
A job queue (SQS + Lambda) starts processing based on an event: a message appears — the function starts, and so on until the queue is empty. A manual trigger is an invocation via API or console for one-off operations: reindexing, migration, recalculation.
| Option | When it fits | Limitations |
|---|---|---|
| Launch scheduler | Recurring tasks on a schedule: reports, synchronization, routine checks | Minimum interval — 1 minute; cron in UTC; with a spike in concurrent invocations, duplicate control is needed |
| Job queue | A stream of similar operations, retries, peak offloading | No time binding; order is not guaranteed without FIFO; handler idempotency is required |
| Manual trigger | One-off operations, debugging, emergency restart | No automation or schedule control; access and protection against accidental launch are needed |
Schedule limitations should be taken into account in advance: cron expressions are calculated in UTC, so the switch to daylight saving time shifts the launch, and the minimum step of one minute is not suitable for per-second tasks.
If an operation lasts longer than the function limit, it is split into steps via a queue — the scheduler launches the first function, which publishes messages, and the handlers pick up the remainder.
In practice, these methods are combined: the scheduler puts a task into the queue, while the manual trigger remains for emergency scenarios and re-runs. This scheme provides resilience to failures and predictable behavior on repeated launches.
How we implement scheduled jobs: project stages
Scheduled jobs are the things that break quietly: a report didn't arrive, synchronization fell behind, emails went out twice.
That's why we build implementation as an engineering process with a verifiable result at every step, rather than "set up a schedule and forget about it."
- Job audit. We collect everything that currently runs on a schedule: system schedulers, scripts on servers, manual runs "on request." For each one, we record the frequency, duration, dependencies on other processes, and the consequences of failure — which jobs are critical and which can be re-run without harm.
- Run map. We break jobs down by type: frequent short ones, long-running ones, ones dependent on external systems. We determine where a calendar-based run is needed, where an event-based run is needed, and where a chain with result passing is needed. This map immediately reveals overlaps that cause jobs to compete for the same data.
- Schedule configuration. We move the rules into a managed scheduling service: time zones, run windows, retries on failure, limiting parallel copies of the same job. The schedule is stored as configuration, not as one engineer's knowledge.
- Logic and permissions. Each job gets its own role with minimal permissions — only the data and operations it needs. Secrets and credentials are moved into a secure vault, not into code.
- Fault-tolerance testing. We run through scenarios: an external system being unavailable, a repeated run, exceeding the runtime limit, a failure in the middle of a chain. We check that the job isn't lost, doesn't duplicate operations, and reports errors correctly.
- Monitoring and alerts. We set up monitoring of whether a run happened, its duration, and its result. Alerts fire on a missed run and on recurring errors, not on every little thing — otherwise the signal gets lost in the noise.
- Handover to operations. We hand over documentation: a job map, the schedule, the procedure for manual restart and rollback. We hold a walkthrough with your team so that support doesn't depend on us.
Describe what jobs you have now — we'll come back with an estimate and a plan for moving them to a managed schedule.
What the client receives after implementation
Everything that appears in the cloud, we hand over to you as code and documentation — no "it's configured in our console, ask Ivan." The package is designed so that your team or another contractor can operate the schedules: with it, you can spin up the jobs from scratch without deciphering someone else's configuration.
- Job configurations as code — definitions of schedules, handlers, and their parameters live in the repository rather than being assembled by hand in the web console. Changes go through review, and rollback is a simple return to the previous version.
- Run schemas — a table of "job → frequency → time zone → what happens when runs overlap → where the result goes." You can see which tasks depend on each other and where the maintenance window is.
- Access policies — roles with the minimum necessary permissions: what a specific job is allowed to do, which engineers can change the schedule, how access is granted and revoked. We separately document that a job cannot exceed its own authority.
- Failure handling — retries with increasing delay, a dead-letter queue for hopeless runs, behavior when an external service is unavailable. It describes how many times we try and when we give up.
- Monitoring and alerts — metrics for successful and failed runs, start delay, alerts to your channel. Configured so that you learn about a problem before the business notices it.
- Operations regulations — what to do on failure, how to temporarily disable a job, how to add a new one, whom to call. The scenarios are laid out step by step, without relying on a specific person.
- Instructions for the team — short guides on typical operations and knowledge transfer: a walkthrough on a recorded call so a new engineer can get up to speed without us.
We separately hand over a list of external dependencies: which services the jobs call, what happens when they are unavailable, and where the boundary of our responsibility lies.
This is what usually surfaces six months after launch — and it's good if the answer is already written down.
Case study: how regular reports stopped failing
The client is a service company with monthly reporting for internal teams and partners. Reports were assembled by a cron script on a single server: it polled billing, the warehouse, and the CRM, consolidated the data, and sent out the files.
While volumes were small, the scheme worked, but as the number of sources grew, the run started to fail — sometimes due to a timeout on the export, sometimes because the server restarted right at the moment of generation.
The share of successful runs hovered around 70%, and the failure was usually noticed by the recipients: the report either didn't arrive or arrived incomplete.
We moved the scheduling and processing to managed services: the Amazon EventBridge scheduler triggers the task on a calendar basis, the processing itself runs in isolated functions, and intermediate results are stored in object storage.
Each step is a separate task with its own retry: if the export from one source fails, only that one is retried, not the entire pipeline.
Errors no longer "hang" in the server logs — they go into a dead-letter queue, and from it you can immediately see which source failed and at which step.
What changed in the numbers
The share of successful runs grew from ~70% to 99.6%: retries and decoupling of steps removed the main cause of failures — a crash on one source while the others were still alive.
Recovery time after a failure dropped from several hours of manual investigation to minutes: the task restarts automatically, and all the engineer has to do is check the dead-letter queue.
A whole class of failures was also eliminated — "silent" misses, when the schedule didn't fire because the server was unavailable. Now the scheduler lives separately from the processing, and its unavailability doesn't block report delivery.
Monitoring tracks not the fact that "the server is alive" but the result: whether the report arrived, whether it fit within the window, and how many retries were needed.
How is scheduled triggering different from event triggering?
Scheduled triggering answers the question "when," event triggering answers the question "why now." A calendar trigger fires based on time: a rule in the scheduler generates a signal at a specified moment, then a handler function executes.
An event trigger waits for a change in state — a file uploaded to storage, a record in a queue, an API call, a change in the database. The difference is fundamental: a schedule knows nothing about the state of the system, an event knows nothing about time.
This is where the choice of trigger comes from.
A schedule is appropriate where the work is tied to the calendar rather than to data: nightly recalculations, report exports, synchronization with external systems according to their schedule, deadline checks and reminders, backup rotation.
An event is appropriate where a reaction is needed immediately after a change: processing an uploaded document, recalculating aggregates after a record is edited, a notification upon payment, draining a message queue.
Mixing them is worth doing deliberately. A common scenario: a schedule launches a sweep, while an event triggers point processing inside it — that way you don't have to poll storage every minute.
The reverse case also works: an event accumulates tasks, and a schedule once an hour processes the accumulated batch, so as not to open a connection for every record.
The practical difference lies in debugging and in behavior during a failure. A schedule is predictable: you know when it will fire, it's easy to reproduce a missed run manually, and lag is visible in the run log.
An event depends on the source, and here redeliveries, message ordering, and duplicate protection matter — the handler must be idempotent, otherwise the same record will be processed twice.
For a schedule, idempotency is also needed, but for a different reason: a repeated run after a failure must not break what has already been computed.
Another criterion is the cost of downtime. If a task must execute even in the absence of traffic, a schedule is more reliable: it doesn't depend on whether an event arrived.
If the work exists only as a reaction to a user action, an event trigger is cheaper and more precise in timing — there's no need to run polling idly.
In practice, systems are almost always hybrid, and the question isn't "which to choose" but "which part of the work to tie to the calendar and which to a change in data."
Common technical concerns about serverless scheduled tasks
A cloud scheduler almost always runs in UTC, and this is the first thing people stumble over when moving tasks from cron on a server.
If the business logic is tied to local time — a report by the start of a shift, a mailing based on the region's working day — the schedule is set not "at 9 a.m." but with an offset, or via a named time zone.
A separate trap is the transition to daylight saving time: a fixed offset produces a one-hour shift twice a year, while a zone with transition rules handles it.
The task ran twice — is that normal or a failure?
Serverless scheduled tasks do not have a strict "exactly once" guarantee: when event delivery is retried, the handler may receive it a second time. That is why the logic is made idempotent — a repeated run must not duplicate a charge, an email, or a record.
The practice: an idempotency key based on the event identifier, an "already processed" check before the action, and separate tracking of completed runs. Then a repeat is harmless rather than an incident.
What happens if a task runs longer than the allotted time?
A function has a duration ceiling, and anything longer is cut off midway — without a transaction and without a rollback. Long processes are broken into steps: enqueuing subtasks, continuing on the next event, saving intermediate state.
This way a long operation turns into a chain of short ones, each of which fits within the limit and survives a retry.
How do you tell that a job did not run?
The scheduler's silence is not a sign of success: the event may have been sent while the handler crashed. Monitoring is built on three signals — the fact of a launch, the result of execution, and the absence of an expected run.
The last is the most important: if a task is supposed to run every hour and there is no run, you need an alert on silence, not on an error. Error and latency metrics plus a run log cover the rest.
Can an existing cron be moved without rewriting the logic?
Yes, if the code is already structured as a separate handler. The schedule is moved into a scheduler rule, the time zone is set explicitly, and the task body stays the same.
The main work is not in the migration but in idempotency and observability: without them, the same logic in the cloud behaves differently than on a server.
Working through these concerns before the start saves weeks of debugging in production. Describe your jobs and current schedule — we will come back with an estimate and a migration plan.
Let's discuss your task and come back with a plan
To come back with a timeline estimate rather than generalities, we need to understand your task in specific terms.
Tell us which scheduled operations need to run on a schedule, at what frequency, and what happens on failure — the launch architecture and the way we monitor execution depend on this.
In the first conversation, we clarify:
- which processes need to be launched on a schedule and at what frequency — once a minute, daily, or by calendar with time zones;
- what exactly each task does: accesses the database, calls external services, generates reports, cleans up stale data;
- the acceptable execution time and data volume per run — this determines whether the task fits into a single call or needs to be split into steps;
- failure behavior: retry the run, notify the responsible person, write to a dead-letter queue, or stop the chain;
- how these operations are currently launched — manually, via cron on a server, through a third-party service — and what gets in the way;
- observability requirements: where error notifications should be sent, whether a run history and metrics are needed;
- access and environment constraints: which cloud you work in, which services are already involved, whether there are data retention requirements.
After the conversation, we document the launch scheme, the list of tasks with schedule parameters, the retry policy, and monitoring points.
On this basis, we prepare a phased work plan, a timeline estimate, and describe the next step — where we start and what will be needed on your side.
Describe the task in whatever form is convenient — we'll come back with an estimate and a plan.
