Zoho CRM Schedules Limit: Plan Batches and Retries

A scheduled Deluge function rarely fails because its logic is wrong. It fails because it runs out of something: time, lines of execution, credits or schedule slots. The Zoho CRM schedules limit is not one number but a set of ceilings that apply at once, and the tightest one decides how much a single run can do. This guide lists those ceilings, turns them into a budget for each run and shows how to retry failed records on later runs instead of inside the same run, with a hypothetical worked example.

Which Zoho CRM schedules limit applies to you

Zoho's pages do not always agree. Where they differ, design for the stricter figure until you confirm what your org allows.

LimitWhat Zoho documentsWhat it means for designActive schedules per orgThe Custom Schedules help page says 10; the edition comparison lists 30 for Enterprise and 50 for UltimateExtra runs per day may each need a scheduleRun time15 minutes for the Schedule category on the Functions limits and quotas page; the older help page says 5 minutesPlan runs to finish well inside 5 minutesLines of execution200,000 per invocation, counting every loop pass and branchNested loops reach it quicklyFunction creditsOne credit per Deluge execution, from a daily allowance set by edition and user countRarely tight for schedulesAPI creditsIntegration tasks use the same credits as the matching API; insert, update and upsert cost 1 credit per 10 recordsShared with every integration in the orgIntegration task concurrency20 simultaneous calls per org on Enterprise, 25 on UltimateMatters when several schedules overlapManual Run NowTwice per dayDo not plan recovery around manual reruns

The API figures come from Zoho's API limits page.

The budgets every run spends

Time, lines and API credits are spent inside each run. Schedule slots decide how many runs you get per day.

Time

Run time goes mostly on waiting. A job that only reads and writes CRM records spends little time per record. A job that calls another system for every record spends most of its run waiting, so that system's response time sets your batch size.

Lines of execution

A loop over 500 records with about 40 statements each executes around 20,000 lines, which is comfortable. Add an inner loop over related records and the count multiplies.

API credits

Updating 100 records one at a time costs 100 credits; one bulk update of the same records costs 10. The Deluge bulk update task accepts up to 100 records per call, so grouping writes is the easiest saving.

Schedule slots

If your org only offers daily or longer recurrence, runs per day equal the number of schedules attached to the function, and every slot one job uses is lost to other jobs.

Sizing a batch from the tightest budget

Work out the batch size from measurements:

1. Run the function in a sandbox with a fixed cap, such as 50 records, and log start and end times to get seconds per record.
2. Take a safe run time. Use 5 minutes even if your org allows 15, then halve it for headroom on slow days.
3. Divide the safe run time by seconds per record. That is your records per run.
4. Check that statements per record times records per run sits far below 200,000.
5. Compare credits per run, times runs per day, with the credits your other integrations leave free.
6. Divide records per day by records per run, round up, and compare with the schedule slots you can spare.

Page numbers only reach about the first 2,000 records of a list, so larger selections need a cursor; our guide to Deluge pagination covers that.

Retry on a later run, not inside this one

Retrying inside the same run spends the scarcest budget. Waiting between attempts burns run time, a system that is down rarely recovers within seconds, and a loop retrying a permanent error can run until the function is stopped.

Instead, keep retry state on the record itself:

• Sync_Status: Pending, Done, Retry or Needs review
• Sync_Attempts: how many times the record has failed
• Next_Attempt_On: the earliest date the record may be tried again
• Last_Sync_Error: a short error code or message

Each run selects Pending records plus Retry records that are due, and classifies failures:

FailureExampleActionTemporaryHTTP 429 or 5xx from the other system, a timeout, TOO_MANY_REQUESTS from CRMAdd one to the attempts and set a later next attemptPermanent for the recordMANDATORY_NOT_FOUND in a bulk update response, a 404 for an unknown IDMark Needs review and keep the errorRun stopped part wayThe run hit a limitNothing: unprocessed records are still Pending

Spread retries across runs: the first in the next run, the second the next night, the third two nights later, and after a fourth failure mark the record Needs review. Cap the share of each run used by retries so a burst of failures cannot crowd out new work. The same ideas apply outside schedules; see our guide to Zoho CRM API error handling.

Worked example: a nightly credit status refresh

This example is hypothetical. A wholesaler on the Enterprise edition refreshes a Credit Status field on its accounts nightly from its billing system. Assume about 2,000 accounts need refreshing each night and the billing system answers in roughly 0.4 seconds per request.

BudgetCalculationResultSafe run time5 minutes, halved150 secondsRecords per run150 seconds divided by 0.4 seconds, rounded down350, of which up to 50 are retriesLines per run350 records at about 40 lines eachAbout 14,000 of 200,000API credits per run2 searches plus bulk updates of 100, 100, 100 and 50 recordsAbout 37Runs needed2,000 new records divided by 300 new per run7 runs, 20 minutes apart from 01:00 ISTAPI credits per night7 runs at about 37 creditsAbout 260

Credits are trivial and lines are far from the ceiling. Time and schedule slots bind: seven schedules for one job is most of the allowance on the older help page's figure. An endpoint that returns many accounts per request would cut time per record and free most of those slots.

The core of each run handles one batch of up to 100 accounts. What follows is a simplified, untested sketch, not production code:

// Simplified, untested sketch
updates = List();
for each acc in batch
{
    upd = Map();
    upd.put("id", acc.get("id"));
    attempts = ifnull(acc.get("Sync_Attempts"), 0).toLong();
    res = invokeurl
    [
        url: billingUrl + acc.get("Billing_ID")
        type: GET
        connection: "billing_conn"
        detailed: true
    ];
    code = res.get("responseCode").toLong();
    if(code == 200)
    {
        upd.put("Credit_Status", res.get("responseText").toMap().get("status"));
        upd.put("Sync_Status", "Done");
        upd.put("Sync_Attempts", 0);
    }
    else if(code == 429 || code >= 500)
    {
        attempts = attempts + 1;
        upd.put("Sync_Attempts", attempts);
        upd.put("Next_Attempt_On", zoho.currentdate.addDay(attempts - 1));
        upd.put("Last_Sync_Error", "HTTP " + code);
        if(attempts >= 4)
        {
            upd.put("Sync_Status", "Needs review");
        }
        else
        {
            upd.put("Sync_Status", "Retry");
        }
    }
    else
    {
        upd.put("Sync_Status", "Needs review");
        upd.put("Last_Sync_Error", "HTTP " + code);
    }
    updates.add(upd);
}
resp = zoho.crm.v8.bulkUpdate("Accounts", updates);

Field names, the connection and the URL are placeholders. A timeout raises an error rather than returning a code, so a full version wraps the call in try-catch and treats it as temporary. It also checks each entry in the bulk update response; any status other than success means that record was not saved.

Suppose the billing system fails for 40 accounts in the 02:00 run: 36 time out and 4 return "account not found". The 36 become Retry and the 02:20 run picks them up. The 4 go to Needs review for someone to correct their billing IDs.

Watching the budget over time

• Log every run: records processed, retries, records sent to review and elapsed seconds
• Alert when elapsed time passes half the safe run time, or Pending records remain at the end of the night
• Check the Failure tab on the Schedules page, where Zoho lists failed schedule executions

Frequently Asked Questions

What is the Zoho CRM schedules limit?

It is a set of limits: active schedules per org (10 on one help page, 30 on Enterprise and 50 on Ultimate in the edition comparison), run time, 200,000 lines per execution and daily credits.

Should a scheduled function retry a failed call straight away?

Usually not. Mark the record for retry and let a later run try again; immediate retries spend run time and rarely succeed.

Do Deluge integration tasks use API credits?

Yes. Zoho counts integration tasks such as searchRecords and bulkUpdate against the same API credits as the matching API calls.

How do I know which limit my schedule will hit first?

Measure seconds per record in a sandbox, then check records per run, lines, credits and runs needed against each limit. Jobs that call other systems usually run out of time first.

Get your schedules sized properly

We review scheduled Deluge functions, size each run against your edition's limits and add retry handling that keeps failures visible. See our Zoho CRM automation services, or talk to us about your schedules.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.