Some of the most important work in an Odoo database happens when nobody is looking. Recurring invoices are generated overnight. Currency rates are fetched. Emails queued during the day are sent in batches. Reordering rules create purchase orders. All of it runs through scheduled actions, Odoo's built-in cron system.
When a scheduled action stops running, nothing crashes. Users keep working, the interface looks normal, and the first sign of trouble is usually a customer asking why they never received an invoice, or a finance team noticing that exchange rates have not moved in two weeks. Here is how scheduled actions work, why they stall, and what to check.
How scheduled actions actually run
Each scheduled action is a record with an interval, a "next execution" date, and the code or method it calls. A small number of dedicated cron workers wake up periodically, look for jobs whose next execution date has passed, lock one, run it, and move its next execution date forward.
Two details matter for hosting:
- The number of cron workers is limited. Odoo's max_cron_threads setting defaults to 2. Jobs are processed one at a time per worker, so a single slow job occupies half of your default capacity for as long as it runs.
- Cron jobs are subject to time limits. In a multi-worker deployment, a job that runs longer than the configured real-time limit is killed. If the job does all its work in one transaction, everything it did is rolled back, and it starts again from the beginning on the next run.
Why cron jobs stall
- A job that outgrew its time limit. A reconciliation or report job that took 30 seconds in the first month can take several minutes once the database has a few years of data. If it now exceeds the limit, it is killed every time, never finishes, and keeps coming back.
- One heavy job starving the others. With only two cron workers, one long import or synchronization job can delay the mail queue and everything else behind it. Nothing fails, but everything runs late.
- An external service that stopped answering. Jobs that call a bank feed, a currency provider, a shipping carrier, or a government e-invoicing endpoint depend on that service. An expired credential or a changed API returns an error on every run, and the job quietly fails in the background.
- Repeated failures that switch the job off. Recent Odoo versions track consecutive failures and can deactivate a scheduled action that keeps failing. That turns a noisy failure into silence.
- Jobs disabled on purpose and never re-enabled. Scheduled actions are often switched off during a migration, a data import, or a staging test. Someone forgets to switch them back on, and nobody notices for weeks.
- Customizations that add their own crons. Custom modules frequently add scheduled actions of their own. If they process every record on every run instead of working in batches, they get slower as the data grows until they hit the time limit.
What to check, and how often
You do not need special tools for this, just a routine.
- Review the scheduled actions list monthly. In Settings, with developer mode on, open Technical, then Scheduled Actions. Sort by next execution date. Any active job whose next execution date is in the past by more than one interval is not keeping up.
- Know which jobs matter to your business. Mark the handful that have real consequences if they stop: the mail queue, recurring invoicing, currency rates, e-invoicing submission, and any custom integration.
- Read the server logs for cron errors. A failing job leaves a traceback in the log every time it runs. On a managed platform, ask your provider how you access those logs and how far back they go.
- Check for inactive jobs you expected to be active. Filter the list to archived or inactive records and confirm each one is off for a reason someone can explain.
- Watch job duration after major data growth. Year-end closing, a bulk import, or a new branch coming online can push a job past its limit overnight.
Staging copies need extra care
A staging or sandbox environment cloned from production also clones its scheduled actions. If those jobs run against a copy of real data, a test environment can send reminders to real customers, submit documents to a live e-invoicing endpoint, or pull from a real bank connection. Before you let scheduled actions run on any copy of production, confirm which ones are active and which outgoing connections the copy can actually reach.
The same staging copy is also the right place to test a fix. If a job is timing out, reproduce it against a recent clone, change the batch size or the logic, and confirm it completes before the change touches production.
Where the responsibility sits
Scheduled actions sit on the line between hosting and application. The hosting side decides how many cron workers exist, what their time limits are, and whether you can see the logs. The application side decides what each job does and how efficiently it does it. When a job stalls, you usually need both sides in the conversation.
That is why it helps to settle, in advance, who reviews scheduled actions and who is called when one fails. Our managed support and SLA service covers exactly this kind of shared application and infrastructure ownership. If you want hosting where staging environments, monitoring, automated backups, and point-in-time recovery are part of the base setup, Plemo provides managed Odoo hosting built for that.
The short version
Scheduled actions fail quietly, and the cost shows up days later in missed invoices and stale data. Keep a short list of the jobs that matter, review their next execution dates regularly, read the logs when something looks late, and treat every staging clone as a place where real jobs can fire. A 15-minute monthly check catches most of these problems before your customers do.