The trigger says on. That does not mean it ran.

It is the first working day of the month. At six in the morning, a flow should send a payment reminder to every customer with an open invoice. At ten, the finance team asks why not one customer has replied.

Someone opens the flow. The schedule is switched on. The screen shows no error.

Then someone opens the run list. There is no run for this morning.

The screen did not lie. It answered the question "is the schedule switched on?" The team needed the answer to a different question: "did the flow run?"

One user reported a webhook trigger that showed as active, on the screen and in the database, while the platform refused the calls sent to it. The fix was to delete the credentials and make them again. They had looked connected and correct.

Another user reported scheduled workflows that stopped running while they showed as active everywhere the user looked. The list of activation errors was empty. Saving each workflow again was the only way the user found to get its schedule back.

A third user reported an email trigger that stopped after the workflow was published. New emails arrived, and no run appeared in the run list. Taking the workflow offline and publishing it again made the trigger work.

A team that runs a pipeline on a schedule, with nobody watching, reported that it had failed on every run for days before they found out.

One reply to a report like these described a check from outside the platform: for each scheduled workflow, compare its last run with how often it should run, and treat silence as the alarm.

Four reports, one pattern. Something said "on" or "active". Only the run history could say what actually happened.

An agent flow does not start by itself. Something starts it. In EpicStaff, a flow can be started five ways: by hand or through the API, on a schedule, by a webhook call, by a Telegram message, or by a parent flow.

Each of these has its own idea of "on". The trigger is part of the harness, the runtime layer your agents run inside, not part of the model (more in who audits the harness). So before you check anything, write down, for each flow, which starts it depends on.

The four checks below work on any platform, ours included. EpicStaff's answer is under each one. Where EpicStaff does not answer a check, we say so, and the check becomes yours. They fit next to the questions to ask any vendor before you self-host.

Find out what "on" or "active" means on your platform. It can mean that the trigger is set to fire. It can also mean that the trigger has fired. These are not the same thing.

In EpicStaff, only schedule triggers have an on/off switch. "On" means the schedule is switched on, not that it has started a run. Webhook and Telegram triggers have no switch: they start the flow whenever a valid call arrives.

So for a schedule, the switch tells you what you intended. For a webhook or Telegram trigger, the question is a different one: do valid calls still arrive? Ask the sending side. Is it still sending, to the right address, with the right secret?

How to stop one flow in an emergency: The workflow that took everything else down with it.

A schedule should tell you when it will fire next. Compare that time with the clock, and with the schedule you meant to set. Check the time zone too.

In EpicStaff, a schedule trigger shows when it will fire next and how many times it has run. It does not show when it last fired; you find that in the flow's run list.

Write down the run count when you look. If a scheduled time has passed and the count has not moved, go to the run list next.

Look at the next-run time itself, too. When a scheduled start fails, the run count and the next-run time are not updated, so the screen can show the trigger switched on with a next-run time that has already passed. A next-run time in the past is a reason to open the run list.

Plan for the server being down, too. If the EpicStaff server is down at a scheduled time, that run is skipped, it is not run later, and the skip is not recorded where a user can see it, so add your own check. After every restart or maintenance window, list the scheduled times that fell inside it, and decide which runs to start by hand.

The run list answers this. Read it against the schedule, not on its own. A run list with no failed runs in it can still be missing a run.

EpicStaff does not alert anyone when a scheduled run fails to start, so add your own check.

The check is a count, not a look. For each scheduled flow, write down how many runs you expect each day or each week. Once a day, compare that number with the run list. A missing run is the alarm. A count that nobody compares is not a check.

A run in the list is not always the run you expected. A colleague may have started the flow by hand during a test. A parent flow may have started it. If you only count runs, a test run can hide a missing scheduled one.

In EpicStaff, each run records what started it, and you can see that in the flow's run list and in the JSON export.

So count only the runs that the schedule started, when you check the schedule. Count only the runs that a webhook started, when you check the webhook.

For webhooks, the sending side needs a record of its own. A webhook call with a known address and the right secret gets "received" from EpicStaff at once, before any run starts; it gets no run id and is not told if the run then fails, so add your own check. Let the sending system log each call it makes. Then compare the number of calls with the number of webhook-started runs in the run list.

Three of the checks above end with "add your own check". One small watcher can do all three jobs:

• Keep a list of each flow, what starts it, and the number of runs you expect per day.
• Once a day, compare that list with the run list. Start by hand; automate it when the list grows.
• For webhook flows, compare the sender's count of calls with the webhook-started runs.
• Send the alert to a named person, not to a shared channel that nobody reads.
• Run the watcher outside the server it watches. A watcher on the same server is down when the server is down.

Check	Where EpicStaff answers it	What you add
Is the trigger on?	Schedules: the on/off switch, which means the schedule is switched on. Webhook and Telegram triggers: no switch; they start the flow whenever a valid call arrives.	Confirm that the sender still sends.
When is the next run?	The schedule trigger shows when it will fire next and how many times it has run.	The time zone, the run count when you looked, and a list of times that fell inside downtime.
Did it run?	The flow's run list.	A daily count against the schedule, outside the platform.
What started it?	The run list and the JSON export record what started each run.	The sender's own log of webhook calls.

Fill in the four rows for each flow. A flow you cannot fill in is a flow you trust on its switch alone.