A job is one piece of work done in the background, outside the request that asked for it. The caller gets a fast answer and the slow work gets its own status, retries and history. You rarely create jobs directly. Pawabase makes one whenever work shouldn’t hold up a request:

​
Job states

Each job records its queue, what it runs (the flow, template or endpoint), where it came from (event, schedule, webhook, api…), its input, attempts, the error from the last attempt, when it started and finished, and how long it took. Jobs started by a request carry its request id, so you can follow them from Requests.

​
Why flows get one attempt

A flow can do anything: charge a card, send an email, create records. Running it again after a failure might do some of that twice, so Pawabase doesn’t retry flows automatically. Instead, you decide:
  • Wrap the part that can fail for a passing reason in a Retry block. It runs its attempt branch up to Attempts times (default 3, at most 10), waiting Base delay seconds (default 0.5) before the second try and doubling each time, up to 30 seconds between tries. When an attempt succeeds the flow continues from the Retry block’s next exit.
  • Make steps safe to repeat: use unique keys, check whether something was already done, and pass the event id along.
  • Re-run what gave up from Studio, after fixing the cause (below).
Mail and webhook jobs are retried automatically, because sending the same message again is safe and expected.

​
Start background work yourself

In a flow, add the Queue flow block to run another flow as a job and continue at once: The block’s output is { "job_id": "…" }. Use it to:
  • Answer fast. A route accepts an upload and returns 202, then queues the processing.
  • Fan out. Loop over a list and queue one job per item, so one bad item doesn’t stop the rest.
  • Wait a bit. Queue a reminder with a delay of 3600 seconds.
For work that must happen at a time of day, or keeps recurring, use a schedule instead of long delays.

​
Read jobs in Studio

Activity → Jobs shows each queue’s depth and counts, a chart of jobs over time, and a table of jobs, newest first. Filter by status and queue. Open a job to see its input, attempts, result or error, and timing. A healthy project has queues that stay short; a queue that keeps growing means work arrives faster than it finishes, or something is failing and retrying. How failed work is retried explains each kind’s retry policy. Waits vary by about 20% so a burst of failures doesn’t retry all at once.

​
Fix and re-run failures

​
One job

Open the failed job, read the error, fix the cause (a bad input, an expired key, a bug in a flow), then Retry. The job is queued again with the same input.

​
Many jobs after an outage

When a partner API was down for an hour, every job that called it failed. Replay queues them again in one go:
  1. Read two or three of the errors to be sure they share a cause.
  2. Wait until the cause is fixed.
  3. Choose Replay and filter: status (failed by default), queue, job kind, and since a number of minutes.
  4. Use Dry run first. It tells you how many jobs would be queued, without queuing anything.
  5. Run it. Up to 1,000 jobs can be replayed at once (200 by default).
  6. Watch the queue drain, and check a few results.
Replay re-runs each job with its original input. Because flows aren’t automatically idempotent, replay only what you know is safe to run again, and prefer flows that check before they act.

​
Permanently failed jobs

Gave up after retrying lists jobs that used every attempt. Retry them, or dismiss ones you’ve dealt with so the list stays useful.

​
From code

​
Show progress to a person

Don’t make a browser poll jobs. Keep progress in a record that the job updates (status: "preparing" → "ready"), and let the app read it or listen to it live with record changes.

​
Limits

​
Troubleshooting