Job Platform
In plain English
Most of what this app does for you happens in the background. When you press "send campaign," the app doesn't send 4,000 messages while you wait — it puts them in a queue and works through them. Same with syncing product feeds, generating content, and recalculating scores.
Normally you never think about this, and that's correct. This screen is for the times when something feels wrong: a campaign that hasn't gone out, a feed that hasn't updated, content you asked for that never appeared.
It shows three things:
- What's waiting. How many jobs are queued, and how long the oldest one has been sitting there.
- Whether it's on time. Each type of work has a target. If the oldest waiting job is older than the target, it's flagged.
- What failed. Jobs that failed repeatedly land in a holding area instead of disappearing. You can see what died, why, and press retry.
The retry is the useful part. Nothing is lost when a job fails — the details are kept, so it can be run again once the underlying problem is fixed.
How to use it
- Click "Job Platform" in the left-hand menu.
- Look at the headline. If everything's healthy, you're done — go back to work.
- If something's flagged as late, check which queue. That tells you what kind of work is delayed.
- Open the failed-jobs area if the count isn't zero.
- Read why a job failed. It's usually an expired connection, a rejected message, or a temporary outage.
- Fix the underlying cause, then click Retry on the failed jobs.
- Discard jobs that shouldn't run — a campaign you've since cancelled, for example.
⏱ ~2 min to check · 💳 Pro+ · 🎯 Know why something didn't happen
Why this matters for your business
Background work is invisible right up until it isn't, and the failure mode is unusually frustrating: nothing appears to go wrong.
You schedule a campaign. The app says it's scheduled. You get on with your day. Three days later someone asks why customers haven't received it, and you have no idea — because from your side it looked fine. There was no error, no alert, just an absence.
That absence is what this screen turns into information. If the sending queue is backed up, you can see it. If 340 messages failed because a connection expired, you can see that too, along with the reason and a retry button.
The holding area for failed jobs is the part that saves real money. Without it, a failed job is simply gone — the campaign never sent, the feed never updated, and recovering means rebuilding and re-triggering the whole thing by hand. With it, you fix the cause and retry, and the original work completes.
This is not a screen you should need often. Most weeks the answer is "everything's fine" and you close it. It earns its place on the days when something's wrong and you'd otherwise be guessing.
What this typically unlocks
| What you get | Typical result |
|---|---|
| "Why didn't that send?" | Answerable in ~2 minutes |
| Work lost to failures | Recoverable via retry |
| Time spent guessing at silent failures | Near zero |
| Early warning of a backed-up queue | Before customers notice |
| Rebuilding campaigns that failed | Unnecessary — retry the original |
What you actually get
Queue health
For every kind of background work:
| Shown | What it means |
|---|---|
| Waiting | Jobs queued and not yet started |
| Oldest waiting | How long the longest-waiting job has been there |
| Status | On time, or late against its target |
"Oldest waiting" is the number that matters. A queue with 2,000 jobs where the oldest is 30 seconds old is working fine — it's busy, not stuck. A queue with 3 jobs where the oldest is 40 minutes old is stuck.
Target times
Different work has different expectations:
| Kind of work | Target |
|---|---|
| Feed delivery | ~5 minutes |
| Sending messages | ~10 minutes |
| Notifications | ~10 minutes |
| Everything else | ~20 minutes |
Beyond its target, a queue is flagged. That doesn't necessarily mean broken — a very large campaign will legitimately take a while — but it means worth a look.
Performance detail
For each queue you also get:
| Measure | What it tells you |
|---|---|
| Latency percentiles | How long jobs typically take, and how long the slow ones take |
| Throughput | How much work is getting done |
| Failure rate | What proportion is failing |
| Cost | What the work is costing to run |
Percentiles are more useful than an average. An average of 4 seconds hides the fact that the slowest 5% take three minutes. Watching the slow end is how you spot a problem developing.
The failed-jobs area
When a job fails repeatedly, it goes here rather than disappearing. Each entry keeps:
| Kept | Why it's useful |
|---|---|
| What it was | Which job, for what |
| Why it failed | The error |
| The full details | Everything needed to run it again |
| Category and area | Groups similar failures together |
Two actions:
| Action | What it does |
|---|---|
| Retry | Runs it again from the stored details, through the same checks as the original |
| Discard | Marks it resolved without running |
Retry doesn't bypass anything. It goes through the same front door as any other job — same permissions, same rate limits, same safety checks. A retry is a fresh, properly-governed attempt.
Grouping matters
Failures are grouped by category and area, which usually turns a long list into a single cause.
| Pattern | What it usually means |
|---|---|
| 340 failures, all one area, all same time | One outage or expired connection. Fix once, retry all |
| Failures spread across areas, over days | Something systemic — worth investigating properly |
| Small steady trickle | Often a specific bad record rather than a system problem |
Access
| Action | Permission |
|---|---|
| View queues, metrics, failed jobs | Settings read access |
| Retry or discard | Settings change access |
Retrying can send real messages to real customers, which is why it sits behind a change permission rather than a read one.
How it works (without the technical bits)
Real merchant scenarios
Scenario A — The campaign that silently didn't send
Setup. Merchant scheduled a 12,000-recipient WhatsApp campaign for a Friday launch. Monday, sales were flat and nobody had mentioned the offer.
Job Platform showed:
Sending queue 2 waiting oldest 4 seconds On time
Failed jobs 11,847 all: comms · whatsapp
Reason on every one: the messaging connection had expired Thursday night. Every send attempt had been rejected.
Without this screen their only evidence was flat sales, and the likely conclusion would have been "the offer didn't land."
Action. Reconnected the messaging account, then retried the batch.
Result. 11,847 messages delivered Monday afternoon. Campaign revenue: about £31,000 — three days late, and recovered entirely.
Rebuilding by hand would have meant re-segmenting, re-approving templates, and re-scheduling. Retry took one click.
Scenario B — Busy versus stuck
Setup. Merchant panicked at 8,400 jobs waiting in the sending queue.
The important number told the real story:
Sending queue 8,400 waiting oldest 11 seconds On time
Oldest waiting: 11 seconds. The queue was moving fast; it was simply large, because a big campaign had just started.
Twenty minutes later it was at zero.
The contrast, from a different day:
Feed delivery 3 waiting oldest 47 minutes LATE
Three jobs, and genuinely stuck — well past its 5-minute target.
Depth tells you how much work there is. Age tells you whether work is happening.
Scenario C — Grouping finding one cause
Setup. Merchant found 1,240 failed jobs and expected a long investigation.
Grouped by area:
| Area | Failures |
|---|---|
| feed · google | 1,198 |
| comms · email | 31 |
| content · blog | 11 |
96% from one area, all within a two-hour window. A Merchant Center outage.
Action. Confirmed the outage had ended, retried the 1,198 as a batch. All succeeded.
The other 42 were genuinely separate issues, handled individually.
Grouping turned what looked like 1,240 problems into two.
Scenario D — Discarding rather than retrying
Setup. Merchant found 800 failed sends from a cancelled promotion. The campaign had been called off after the jobs were queued but before they ran.
Retrying would have sent a promotion that no longer existed — with a discount code that had been deleted. Customers would have received an offer they couldn't use.
Action. Discarded all 800.
Why discard exists. Not every failed job should run. Retry is the default, and sometimes the right answer is "this shouldn't happen at all."
Scenario E — Watching the slow end
Setup. Everything on-time, no failures, but the content queue's slowest jobs had crept from ~40 seconds to ~4 minutes over three weeks.
Nothing was flagged. Four minutes was still inside the 20-minute target.
But the trend was one-directional, and the merchant investigated. Their image-generation jobs had grown as product photography got larger, and each job was doing more work.
Action. Resized source images before processing.
Result. Slowest jobs back to ~50 seconds, and processing costs down about 60%.
Nothing was broken. The trend was a leading indicator of something that would eventually have broken.
Best practices
✅ Check "oldest waiting," not the queue size. Scenario B.
✅ Come here first when something didn't happen. It's the fastest way to distinguish "didn't run" from "ran and didn't work."
✅ Fix the cause before retrying. Retrying into the same failure just refills the list.
✅ Retry in batches by area. Failures usually share one cause — Scenario C.
✅ Discard jobs that shouldn't run. Scenario D.
✅ Watch the slow end of the latency spread, not just the average.
❌ Don't retry blindly. Check whether the work is still appropriate.
❌ Don't panic at a deep queue with a young oldest job. That's busy, not broken.
❌ Don't ignore a small steady failure trickle. It's usually a specific bad record that will keep failing.
❌ Don't leave failed jobs unresolved indefinitely. Retry or discard, so the count means something.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Queue health and status | — | — | ✓ | ✓ | ✓ |
| Target-time flagging | — | — | ✓ | ✓ | ✓ |
| Latency, throughput, failure rate | — | — | ✓ | ✓ | ✓ |
| Cost per queue | — | — | ✓ | ✓ | ✓ |
| Failed-jobs console | — | — | ✓ | ✓ | ✓ |
| Retry and discard | — | — | ✓ | ✓ | ✓ |
| Cross-store queue view | — | — | — | ✓ | ✓ |
Frequently asked
Do I need to check this regularly? No. It's a diagnostic screen. Come here when something didn't happen as expected.
What does "oldest waiting" mean? How long the longest-waiting job has been queued. It's the best single indicator of whether work is moving.
A queue is flagged late. Is something broken? Not necessarily. A large campaign legitimately takes time. Check whether the age is still growing — if it's falling, it's catching up.
Is a failed job lost? No. The details are kept in the failed-jobs area so it can be retried.
Does retrying skip safety checks? No. It goes through the same front door as any job — same permissions, rate limits, and checks.
How long are failed jobs kept? Until you retry or discard them. Resolve them so the count stays meaningful.
Why do I need settings permission? Retrying can send real messages to real customers, so it's a change action rather than a read one.
What if retrying fails again? The cause hasn't been fixed. Read the error, resolve the underlying issue, then retry.
See also
- Daily Ops overview — the day-to-day work queue
- Weekly digest & engine audit — wider system health
- Rules & executions — automations that create background work
- WhatsApp engine — a common source of sending jobs
- Feed autopilot & rules — a common source of feed jobs
- Team & permissions — the settings permissions needed here
- Troubleshooting — wider problem-solving