Dispatcher and Performer

This is one of the clearest examples of where Automation Watchdog adds value in an RPA program.

The problem

A dispatcher loads work into a queue and a performer processes that work afterward. Support teams need confidence that:

• the dispatcher finished in time
• the performer started when expected
• the performer kept making progress until the queue was done

Recommended design

Watch 1

Dispatcher watch

Use a scheduled or explicitly activated missed-action watch to confirm the dispatch stage completes inside its expected window.

Watch 2

Performer watch

Use a missed-action watch with cascading timing so the performer must keep proving progress while queue work remains.

Good feature choices

• Use Activate on Deactivation if the performer should begin monitoring as soon as the dispatcher fully finishes
• Use Condition By Queue if the same performer process works across multiple queues and each queue should be tracked independently
• Use Threshold Monitoring if you want item success rate to matter in addition to timing

Check-in pattern

1. Dispatcher activates or starts inside its watch window.
2. Dispatcher checks in after successfully loading work.
3. Dispatcher deactivates when it is done.
4. Performer activates from that handoff or by first valid check-in.
5. Performer checks in per item, per batch, or at another meaningful progress point.
6. Performer deactivates when the queue is complete.

Why this design works

It separates two different operational expectations:

• dispatch should happen
• processing should continue

That usually produces clearer alerts than trying to force both expectations into one watch.

Common mistake

Trying to model the full flow with one watch often makes alerts harder to interpret. Separate watches usually produce cleaner run ownership and better support signals.