Event-Driven Monitoring

Not every workflow should be monitored on a fixed calendar. Some runs should only begin monitoring when a real event occurs.

Good fits

• a queue receives new work
• a file arrives
• an API request creates a new task
• another workflow reaches a handoff point

Recommended design

Use a non-scheduled missed-action watch and activate it in one of these ways:

• explicit activation API call
• Activate On Check-In if the first valid check-in should start the run
• Activate On Deactivation if the run starts as the next stage in a workflow chain

Why event-driven design helps

It keeps monitoring aligned to real operating activity. Teams avoid artificial schedule windows for work that is not supposed to happen on a fixed clock.

Watch for this mistake

If the watch should only exist when work actually exists, avoid giving it a recurring schedule just because the process is long-running overall. That often creates extra noise and weakens the alert signal.