Scheduling Background Jobs

This is the most important setup step in REDA, and the easiest to miss. A brand-new REDA org creates leases perfectly well — and then never bills them, because the recurring invoicing, late fees, month-to-month fees, inflation, straight-line schedules, snapshots, and recurring inspections are all background jobs, and REDA ships with none of them scheduled. Scheduling them from the Admin Console is a mandatory go-live task. This article shows you what runs out of the box, the full catalog of jobs, how to schedule and abort them, how big the batches are, and how to diagnose the classic silent failure where "the invoices just never happened."

What ships running, and what you must schedule

Two things run in a fresh REDA org without you doing anything. Both are daily housekeeping schedules, and neither appears in the console's job catalog:

Everything else — all 13 of the jobs in the next section — waits for you to schedule it. The cadence of each is an administrator's decision, not something fixed at install.

The 13-job catalog

These are the jobs you schedule in the console. The default times below stagger the work across the night; the last column is what silently doesn't happen if you leave a job unscheduled.

A few anchors worth remembering: recurring charges run at 1:00 AM, late fees at 10:00 PM, and the only job that defaults to the 1st of the month is the snapshots (6:00 AM). Note that the two monthly fee jobs still default to running daily — 10:15 AM and 10:15 PM, fifteen minutes after their per-day siblings. That is deliberate: the fee is monthly (charged once per invoice), but the job has to run every day to catch invoices as they become eligible. Schedule those two monthly and most fees will never be charged. Late-fee and month-to-month invoices are created as children linked to the overdue or parent record, and they're safe to run daily — REDA tracks what it has already charged and won't double up.

Scheduling a job

Aborting a job

To stop a scheduled job, abort it from the same tab. REDA asks you to confirm with "Abort this scheduled job? Future runs will stop immediately. In-flight executions complete normally." — so a run already underway finishes, and only future runs stop. Abort is deliberately restricted to REDA's own catalog jobs; you can't abort unrelated platform jobs from here.

Batch sizes

Several jobs process records in batches, and the batch size is a setting. There are six batch-size settings, all set to 50 by default: recurring charges, delayed move-out, monthly late fees, per-day late fees, monthly month-to-month fees, and per-day month-to-month fees. They live in Global App Settings, and each job reads its setting at run time — so a change takes effect on the next run with no need to reschedule.

Two jobs are fixed and not configurable: both Inflation Adjustment jobs process one record at a time by design. There's no size setting for them, so don't try to speed them up with one. You'll only need to revisit batch sizes if a run is slow or bumping platform limits.

Timing, time zones, and missed days

Two operational facts matter here, and both can catch out a new administrator.

Jobs run in the time zone of the user who scheduled them. If you schedule the 1:00 AM recurring-charge job from a user whose time zone differs from your operating region, it will run at 1:00 AM their time. Schedule from a user set to the org's operating time zone so the times mean what you expect.

Every batch writes a run log with success and failure counts, and failures email your administrators. Monitor the runs in REDA Async Logs.

The go-live checklist

The defaults are staggered so that dependencies hold — inflation re-rates a lease before the 1:00 AM recurring invoicing bills it. When you shift the times, keep inflation before recurring charges.

Worked example: Meridian goes live

On go-live day, the administrator at Meridian Properties schedules all 13 jobs at their default times. Three leases each carry monthly rent of 1,200.00, all due to bill on the 1st. The next morning, the 1:00 AM recurring-charge run has created three invoices of 1,200.00; the 10:00 PM late-fee run created nothing, because nothing was overdue.

Contrast that with the same org where the jobs were never scheduled: the same three leases, the same 1st of the month — and no invoices anywhere, and no error anywhere. The only symptom is absence. That absence, in a fresh org, is almost never a bug; it's an unscheduled job.

The Scheduled Jobs tab: the shipped job catalog grouped by area (Inflation Adjustment, Recurring Charges, …), each job marked Not Scheduled with its recommended cron and a Schedule button — the fresh-install state before any job is turned on.

The Scheduled Jobs tab — the job catalog, each entry showing its recommended run time so you can schedule them to match your business hours.

A REDA Async Log record from a Recurring Charges run — batch class, success and failed record counts, and the details of what failed.

Where to go next

1. Go-Live Checklist — this scheduling step is at its core.
2. REDA Async Logs — monitor what each job did and catch failures.
3. Global App Settings — where the six batch-size settings live.
4. How Recurring Invoicing Works — what the recurring-charge job produces, and recovery after a missed day.
5. Late Fees and Inflation Adjustments — the other automations these jobs drive.

Frequently asked questions