The Day Your Workspace Runs Without You
Sixty-five scheduled jobs run against a workspace, and the order they run in is a piece of design. Data is prepared before anything is pruned, prices are fetched before anything is charged, and every message that reaches a person happens after all of it.
By the time anybody opens the product in the morning, about forty jobs have already run.
The scheduled half of an operations system is the half nobody sees, and it is where most of the value in a product like this actually accumulates — reminders that reach somebody, figures that are current, records that age out, integrations that stay in step. Reading the timetable is the fastest way to understand what a system does when nobody is asking it anything.
The night is arranged in four movements
| Window | What happens | Why in that order |
|---|---|---|
| Just past midnight to one | Dashboard figures are built; purchase orders close; reorder points are recalculated | Computation first, on yesterday's complete data, before anything is removed. |
| Two to half past | Debug records, retention policies, logs, runtime state and the recovery centre all prune | Deletion after computation. Anything the earlier jobs needed has already been read. |
| Three to four | Exchange rates, the plan catalogue, billing reconciliation, then add-on charges | Fetch before charge. Money is only moved once the figures it depends on have been refreshed. |
| Half past five to a quarter past ten | Every message that reaches a person | Notification last, so what people are told reflects the whole night's work rather than a partial state. |
That ordering is the single most instructive thing in the file. Each movement depends on the previous one having finished, and the gaps between them are the design — not spacing for its own sake, but a sequence with dependencies in it.
Fetch before charge is the one to notice
Exchange rates are refreshed at three, the plan catalogue five minutes later, billing reconciled at ten past, and add-on renewals charged at twenty to four. A charge computed before its price list was refreshed would use yesterday's figures, and nothing about the resulting transaction would look wrong. Forty minutes of separation is what keeps that from being possible.
The morning is a single conversation, staged
From half past five to a quarter past ten, roughly thirty jobs send something to somebody, and they are ordered by who is waiting and how urgently.
-
Half past five: the open attendance day
First, because it concerns yesterday and because the person who can resolve it is about to start today.
-
Six to a quarter past seven: platform-side digests
Billing, adoption, security and operations summaries for whoever runs the platform — before the working day, so a problem is known before customers meet it.
-
Half past seven to nine: work reaching your own people
Task deadlines, recurring tasks spawned, overdue invoice workflows, low stock, expiring batches, dead stock, approval queues.
-
Nine to five to ten: chasing, in order of who is waiting
Customers, suppliers, deliveries, quotations, documents, then the internal digests, then people matters — leave and attendance corrections last.
-
A quarter past ten: engagement email
Deliberately after everything operational. Nobody should receive a nurture email before the reminder about the invoice they owe you.
The order of a morning's emails is a statement about whose time matters.
What runs more often than daily
Five cadences below a day, and each frequency is a claim about how fast the thing it watches changes.
- Every minute — two heartbeats, one for the scheduler and one for the queue worker. These exist so that silence is detectable, which is the only way an absent scheduled job is ever noticed.
- Every five minutes — pending mobile money payments resolved, and quotations analysed. Both are cases where somebody is actively waiting for an answer.
- Every fifteen minutes — support response deadlines checked, because a breached promise fifteen minutes late is still actionable and an hour late is not.
- Hourly — knowledge index synchronisation, tax filing retries, signature synchronisation, scheduled report delivery, supplier payment reconciliation, and the video feed.
The heartbeats are the ones worth understanding. Every other job on this list produces an effect somebody would eventually notice if it stopped. A scheduler that dies produces no effect at all — the website answers, the screens work, and forty jobs quietly do not run. A heartbeat every minute turns that from an invisible failure into an alarm about silence.
The longer cycles
Two weekly digests go out on Monday mornings — an operational summary and a review of tax rates that may need checking. Four monthly jobs run in the first hours of the month: a security contact file regenerated, leave accrued, partner commissions calculated, and overtime derived from attendance on the second rather than the first.
That last one is a nice piece of care. Overtime is derived from a month of attendance, and running it on the first would race the last day of the month. A day's delay costs nothing and removes the question entirely.
Two declarations on every single job
All sixty-five carry the same two guarantees: no run overlaps its own previous run, and no job runs twice because more than one server is up.
Those sound like infrastructure details and they are what make the timetable trustworthy. Without the first, a job that starts taking longer than its interval silently begins running concurrently with itself, which is how a synchronisation duplicates and a purge deletes something twice. Without the second, adding a server doubles every reminder your customers receive.
Applying both universally rather than case by case is the important part. A default that has to be remembered is a default that gets forgotten on the sixty-sixth job, and the failure will be in production at three in the morning.
Making the timetable yours
The sequence and the guarantees are sound. What organisations spanning several time zones ask for is control over when the morning happens.
A per-organisation delivery window
Reminders arriving at nine in your morning rather than nine in the installation's, which matters most for the messages that leave the building.
A visible schedule per workspace
Which of these jobs concern you, when they last ran and what they did, rather than a timetable only the operator can read.
Duration tracking per job
How long each one takes over time, so a job drifting towards its own interval is visible before it starts overlapping.
We publish scope, not dates.
Scope scheduled operationsWhat AWRA OpsHub does today
- Sixty-five scheduled jobs covering computation, pruning, billing, integration, chasing and reporting.
- A deliberate nightly order — compute, then prune, then fetch prices, then charge, then notify — with each stage separated from the one it depends on.
- A morning sequence of roughly thirty notification jobs ordered by who is waiting, with engagement email deliberately last.
- Heartbeats every minute for the scheduler and the queue worker, so an absent scheduled job is detectable as silence.
- Five-minute cadences for the cases where somebody is actively waiting, and a fifteen-minute cadence for support response deadlines.
- Hourly retries for tax filings, payment reconciliation and integration synchronisation.
- Weekly Monday digests and four monthly jobs, with overtime derived on the second of the month rather than racing the last day of the previous one.
- Non-overlapping execution and single-server execution declared on every one of the sixty-five, rather than case by case.
- Start, finish, duration and failure recorded for scheduled work.
More we can add to your workspace
- A per-organisation delivery window, so a workspace in another time zone receives its morning reminders in its own morning.
- A workspace-visible schedule, showing which jobs concern you, when each last ran and what it did.
- Duration tracking over time per job, so one drifting towards its own interval is visible before it begins overlapping.
- A per-organisation opt-out from a whole class of scheduled work, rather than per notification type.
- A dependency declaration between jobs, so the ordering is enforced by the schedule itself rather than expressed as clock times spaced apart.
- A catch-up run for a job that missed its window because the scheduler was down.
Where we point you to a specialist
- We will keep non-overlapping and single-server execution on every scheduled job rather than deciding case by case. A default that has to be remembered gets forgotten on the next one added, and that failure appears in production at three in the morning as a duplicated synchronisation or a double purge.
- We will not send engagement email before operational reminders. The order of a morning's messages is a statement about whose time matters, and a nurture message arriving before a reminder about an unpaid invoice makes the wrong one.
- When your organisation should receive its reminders is a question about your working day, and the honest position today is that the timetable runs on the installation's clock. We would rather say so than imply a per-workspace window that does not yet exist.
A per-organisation delivery window is the contained piece with the widest effect, because everything before the morning block is machinery and everything in it is a message to a person whose morning may not be ours.
Our take
A schedule is the most honest description of a product available, because it lists what happens when nobody asks. What is worth taking from this one is the ordering rather than the contents: compute before you prune, fetch before you charge, and notify after everything else. Those three rules resolve most sequencing questions on their own, and each of them prevents a failure that would look like nothing at all — a dashboard built from partially purged data, a charge struck against yesterday's prices, a reminder describing a state that changed twenty minutes later. The gap that remains is a time zone gap. Everything before half past five is machinery and the clock does not matter; everything after it is a message to a person, and that person's morning may not be the installation's.
Five questions to ask about scheduled work
How many scheduled jobs are there?
A good answer sounds like
A number.
What ours actually is
Sixty-five, from every-minute heartbeats to monthly accruals.
Can a job overlap itself?
A good answer sounds like
No.
What ours actually is
No. Non-overlapping and single-server execution are declared on every one, not case by case.
What order do they run in, and why?
A good answer sounds like
A stated sequence.
What ours actually is
Compute, prune, fetch prices, charge, notify — each stage separated from the one it depends on.
How would you know the scheduler had stopped?
A good answer sounds like
A heartbeat.
What ours actually is
Two, every minute — one for the scheduler and one for the queue worker — because an absent job produces no symptom of its own.
Do reminders arrive in my time zone?
A good answer sounds like
An honest answer.
What ours actually is
Not today. The timetable runs on the installation's clock, and a per-organisation delivery window is the first item on the list of what would be added.
Ask any vendor for their schedule
It is a better description of what a product does than any feature list, and the ordering tells you whether anybody thought about the dependencies between the parts.
Talk through operationsFrequently asked questions
Why do so many reminders arrive between nine and ten?
Because that block is deliberately the last stage of the night, after computation, pruning, price refreshes and billing have all completed. A reminder sent earlier would describe a state that was still changing. Within the block the order is by who is waiting — customers, then suppliers, then deliveries and quotations, then internal digests, then people matters.
What time zone are these times in?
The installation's, which is a single value rather than something set per workspace. For everything before half past five that is immaterial — it is machinery. For the morning block it means a workspace several hours away receives its reminders at a time that suits the installation rather than its own working day, and a per-organisation delivery window is the change that would fix it.
Can two of these run at the same time?
A job never overlaps its own previous run, and never runs twice because more than one server is up. Both are declared on all sixty-five rather than decided individually, which matters because a default that has to be remembered gets forgotten on the next one added — and that failure appears as a duplicated synchronisation or a double purge in the middle of the night.
Why is overtime derived on the second of the month?
Because it reads a full month of attendance, and running it on the first would race the last day of the previous month. A day's delay costs nothing and removes the question entirely. It is a small piece of care that is worth noticing, because the alternative produces a figure that is occasionally short by one day's work and never obviously wrong.
What happens if the scheduler stops?
Nothing visible, which is the whole problem. The website answers, every screen works, and roughly forty jobs quietly do not run. That is why two heartbeats are recorded every minute — one for the scheduler and one for the queue worker — so the failure is detectable as silence rather than through its consequences weeks later.
Can we switch some of these off?
Per notification type, yes — every reminder that reaches a person is gated by a setting and a cadence held per organisation. What is not available today is switching off a whole class of scheduled work for one workspace, or asking for a catch-up run when a job missed its window. Both are named on the list above.
