The Binse Schedules user guide.

Copyright 2026 Binse Analytics. All rights reserved.

Schedules is the workspace that runs things for you. A flow you would otherwise open and press Run on every Monday morning, a dashboard whose numbers are a day old by the time anyone looks at them, a file somebody drops on a share that nobody notices until Thursday: all of that is a schedule.

You point it at work you have already built - a flow, a dashboard, or several of them in order - and say when it should happen. Windows starts it at that time, under your own account, with no window on screen and nothing for you to remember. Afterwards there is a row in the run history saying what happened, how long it took and how many rows it wrote, and if it went wrong, which tool broke.

Nothing new is installed, no service is created, no port is opened and nobody needs administrator rights. It is the same product, the same licence and the same machine: the only difference is that the Run button is being pressed by the clock instead of by you.

Contents

• What Schedules is for
• Before you start
• Getting started
• The screen
• Buttons and controls
• Creating a schedule
• Steps: what a schedule does
• Triggers: when it happens
• Trigger reference
• Parameters
• Relative dates
• Delivery
• Run now
• Switching a schedule off
• The run history
• One run in detail
• History reference
• Failure notification
• What Windows sees
• Where everything lives
• Uninstalling, reinstalling and repair
• Troubleshooting
• Glossary

What Schedules is for

Three jobs, and they are the ones that fill a Monday.

Work that has to happen again. A flow that reads last week's exports, cleans them and writes a spreadsheet is finished work. Running it is not: somebody has to be at the machine, remember, and wait. A schedule does the remembering.

Numbers that go stale. A dashboard is only as current as the last time its tables were read. A schedule reads them again on a timetable, so the dashboard is right when it is opened rather than when it was last opened by the person who built it.

Reaching people who have none of this. A refreshed dashboard can be written out as one file to a folder or a share, and that file opens in any browser with nothing installed. The people who need the answer never see the app at all: they see a link to a file that was correct at seven this morning.

A schedule is not a general job scheduler. It runs Binse flows, Binse dashboards and Binse diagrams, and that is deliberate: it is a part of this product, not a cron front end that happens to ship with it.

Before you start

Three limits. None of them is a bug being worked on; each is a decision, and knowing them now saves an afternoon later.

Scheduled runs happen only while the machine is on and you are signed in to Windows. Sign out and nothing runs. Lock the screen and it still runs, because a locked machine is still a signed-in one, and so does a laptop with the lid shut only if it is not asleep. Making a task run while nobody is signed in requires Windows to store your account password, which on a managed machine is a conversation with whoever administers it - so stage one does not ask for it. If the run has to happen at three in the morning on a machine nobody is sitting at, leave that machine signed in and awake.

Anything a browser has to draw is not offered. One rule, applied everywhere, and it explains the whole delivery list. A scheduled run has no window, so it cannot take a picture of anything. A dashboard is therefore delivered as a single HTML file and nothing else: PDF and PowerPoint there are built from pictures of the pages. A diagram is delivered as a web page, an SVG or a PDF - all three written straight out of the document, none of them photographed - and as no picture format at all, because PNG and its relatives are drawn into a canvas by a browser. The formats that are offered are not consolation prizes: the dashboard file opens in any browser with no install, keeps its filters and cross-filtering, and prints with Ctrl+P; the diagram's SVG is sharp at any size and goes into Word, PowerPoint and Confluence as it is. Anything else is a hand export from Dashboards then Export or Diagrams then File then Export, which are still there whenever you want one.

One run at a time, inside the app. Press Run now while something is already running and you are told to wait, on purpose: two runs sharing the flow engine's cache is a race nobody needs. Note the boundary, though - a scheduled run is a separate process started by Windows, and it does not know what the app is doing. Two schedules set to the same minute will both start. Stagger them by a few minutes and the problem does not arise.

And one thing Schedules deliberately does not own: email. There is no mail server setting here and no password for one. Sending mail is a tool in the flow engine, so "email me when this breaks" is a flow of your own that Schedules runs on failure. See Failure notification.

Getting started

1. Open the app and choose Schedules from the home page, or use the workspace switcher at the top left of any workspace. The address is http://127.0.0.1:8767/hub/.
2. Press New schedule and give it a name. The name is what you will read in the history at half past seven on a Monday, so make it the sentence you would say: Nightly sales refresh.
3. Press Add a flow, Add a dashboard or Add a diagram, and choose one from the list. The lists are the flows in your Workflows folder, the dashboards in your Dashboards folder and the diagrams in your Diagrams folder, so anything you have saved is already there.
4. Under When it runs, pick a trigger and fill in the fields it shows. Start with Every day at a time you will be at the machine, so you can watch the first one happen.
5. Press Save. The schedule is written to disk and Windows is given the trigger.
6. Press Run now on the new row, without waiting for the clock, and watch it appear under Recent runs. If it works by hand it will work at seven.

That is the whole loop. Everything after this is detail.

The screen

One page, two lists.

Schedules, at the top, is one row per schedule: its name, the steps it runs, when it runs next, and how the last run went. The buttons on the right are Run now, Edit and Delete. Under the list is the reminder that scheduled runs need you signed in to Windows.

Recent runs, underneath, is the newest twenty-five runs of everything, newest first: which schedule, when it started, how long it took, how many rows it wrote and how it ended. Click the name of a schedule in that list to open the detail of that one run.

The page refreshes itself every fifteen seconds, so leave it open and it keeps up on its own.

Buttons and controls

Creating a schedule

A schedule is four answers: what to run, when, what to hand it, and what to do if it breaks. The editor asks them in that order.

A name. It appears in the list, in the history, in the Windows task, and in the parameters handed to a failure flow. Names do not have to be unique, but two schedules called Refresh will make a run history nobody can read.

Steps. At least one. See Steps.

A trigger. One per schedule. See Triggers.

A failure flow. Optional. See Failure notification.

Switched on. Ticked by default. Unticking keeps everything and stops it happening.

Press Save and two things happen: the schedule is written as a file of its own, and Windows is told about the trigger. If Windows refuses the trigger for any reason, the schedule is still saved and you are shown what Windows said. That way a rejected trigger costs you a message, not the ten minutes of typing you just did.

A schedule that could not possibly run is refused before it is saved, naming the thing that is wrong - a step with no flow chosen, a delivery with nowhere to write to, a weekly schedule with no days ticked. Whether the flow file is actually where it says it is gets checked at run time instead, because a schedule pointing at a share that happens to be offline this minute is not a broken schedule.

Steps: what a schedule does

A step is one piece of work. A schedule runs its steps in order, and stops at the first failure. That is the whole model, and it is what makes a chain sensible: if the flow that rebuilds the figures fails, the dashboard that reads them is not refreshed, and nobody is sent a file full of yesterday.

Running a flow. Choose one of your saved flows. It runs through exactly the same engine the Run button in Data Flow uses, after the same preparation: your parameter values are substituted, the Interface tools' actions are applied, and macros are expanded. There is no second way of running a flow, which is the point - caching, containers, macros and parameters all behave the way they do when you press Run yourself. What the step reports afterwards is how many tools ran, how many rows the Write Data tools wrote, and how many tables were published to Dashboards.

Refreshing a dashboard. Choose one of your saved dashboards. Every table it uses is read again from wherever it came from, so the dashboard is current. Refreshing on its own changes nothing you can see until somebody opens the dashboard - which is exactly what you want for a dashboard people open in the app. To send it to somebody instead, add a delivery: see Delivery.

Refreshing a diagram. Choose one of your saved diagrams. A diagram whose shapes are linked to data is a picture that is only true until the data moves: the rack that was green is blocked this morning, and nobody has opened the file to find out. A diagram step reads the diagram's data sources again, writes the new rows into the shapes they are linked to, evaluates every rule so the shapes recolour and their text is rewritten, recomputes any charts on the page, and saves the diagram. Open it afterwards and it is already right; deliver it and everyone else sees the same.

Tick which data sources to refresh under Data sources to refresh. Leaving them all ticked means all of them, including any you add to the diagram later - which is what you want unless one source is slow or only meaningful on another day. Two kinds can be read without anybody at the machine: a file given by its path, and a connection with a query. A file somebody picked in a browser file dialog cannot, because what the diagram stored is the name of the file rather than a path; give it a path in the diagram's Sources sheet and a schedule can refresh it.

A Data Flow output is the first of those: have the flow write its table where it always writes it, link the diagram to that file, and put the two steps in one schedule in that order.

Several in order. Add as many steps as the job needs. The usual shape is two or three:

1. Flow - read the new exports, clean them, write the table.
2. Dashboard - refresh the dashboard that reads that table, and deliver it to the team's share.
3. Diagram - refresh the diagram linked to the same table, and deliver the picture beside it.

All of it happens at seven, in that order, and if the first one fails the rest do not run and the files on the share stay yesterday's rather than becoming a wrong today's.

The step kinds

What a step is refused for

A dashboard is delivered as html: one HTML file. A diagram is delivered as html, svg, pdf. See Delivery for what each one writes, and Before you start for why the list stops there - BMP, GIF, JPEG, PNG, TIFF, WebP, a web page with a picture map are all drawn by a browser, and a scheduled run has no window.

Triggers: when it happens

One trigger per schedule, and six to choose from. Four of them are clock triggers and become a Windows scheduled task, one watches a folder, and one is no trigger at all. Whichever you pick, the fields it needs appear under it as soon as you choose it.

Only when I run it. No trigger at all. The schedule sits in the list waiting for Run now. Useful for a job you want saved, named and repeatable but not automatic - a month-end pack that runs when somebody says the ledger is closed.

Every few hours. Runs every so many hours from when the task is created, round the clock. Every 3 hours on a sales feed that lands whenever a region closes its books.

Every day. One time, every day. 07:00 on the overnight refresh, so the dashboard is right before anyone opens it.

Every week. One time, on the days you tick. MON at 07:00 for the pack that is discussed at the Monday meeting. Tick several days when the answer is wanted more than once a week but not daily

• MON, WED, FRI at 06:30.

Every month. One time, on one day of the month. Day 1 at 06:00 for the month-end pack. The day stops at 28 on purpose: pick the 31st and the schedule would not exist in February, and a schedule that silently skips a month is worse than one that runs three days early.

When a folder changes. Watches a folder and runs when anything matching your pattern appears, changes size, or is modified - and a file being deleted counts too. Watch \\server\incoming, matching *.csv, check every 5 minutes for the case where the trigger is really "when the finance team drops the export".

Two things to understand about the folder trigger, because they are not what "watch" usually means. It is a poll, not a watch: Windows starts a task every few minutes, the runner compares what is in the folder now with what it saw last time, and does nothing if the answer is the same. Nothing of ours sits resident on your machine, which is the promise, and the cost is that "when the file lands" really means "within the interval you chose". And because every check is a run, a five-minute check writes a skipped row to the history every five minutes: nearly three hundred a day. That is why the history keeps the newest rows only, and why a fifteen-minute check is usually the kinder answer unless minutes genuinely matter.

The other cost of a poll is a file still being written. The signature includes each file's size and modification time, so a large file being copied in looks like a change and may fire while it is still half there. Where that matters, have the sender write to a temporary name and rename it when it is finished, and match the pattern to the final name.

A worked example of each

What each field is

Trigger reference

Generated from the validator itself, so these are the bounds it actually enforces and the words it actually refuses in.

The example commands above are what Windows is given for the worked examples in the table before this one.

A time is checked against the pattern ^([01]\d|2[0-3]):([0-5]\d)$, which is the long way of saying 00:00 to 23:59 with a leading zero where one is needed.

Parameters

A parameter turns one flow into a flow that can be run many ways. In Data Flow you add a Parameter tool (or one of the Interface tools) and give it a name; anywhere $Name appears in another tool's settings - a path, a filter expression, a formula - it is replaced before the run starts. A flow that reads C:\exports\$Month\sales.csv is one flow, not twelve.

A schedule supplies those values. Open the flow step, press Add a parameter, and give the name and the value. The name is the parameter's name in the flow, without the $.

Two rules worth knowing, both of which are the same in the app and here:

• Substitution happens on a copy of the saved flow, before anything runs. What runs is an ordinary flow with ordinary settings, so an error message points at a real path rather than at a placeholder, and the run cache sees a different flow for different values instead of handing you last month's answer.
• A name the flow does not declare is ignored, and a $Something the flow has no parameter for is left exactly as it is. It is far more likely to be a Windows environment variable or a currency symbol in a label than a typo.

Leave a parameter out of the schedule entirely and the flow's own default is used instead - and on a Date Picker tool that default can be a moving one, worked out afresh on every run. That is the mechanism behind relative dates, below, and it is why the answer to "do I need a second copy of this flow for last month" is no.

Where a value can go

The tools that declare one

A schedule can supply a value for any of these, by the name the tool declares.

Relative dates

The nightly question is almost always about a moving date: last month, yesterday, the year so far. Answering it with a fixed date means editing the schedule every month, and nobody remembers to.

The moving part lives on the flow, not on the schedule. In Data Flow, use the Date Picker interface tool instead of a plain Parameter, and set Default to rather than typing a fixed default. The tool then hands the flow an actual date every time it runs, worked out on the day it runs.

These are the choices, and what each one worked out to on the day this guide was built (16 September 2026):

So the shape of a month-end flow is: a Date Picker tool named AsAt, defaulting to The last day of last month, used as $AsAt in the filter or the output path. The schedule that runs it on the first of the month supplies no value at all for AsAt, and each run gets the right date on its own.

Type a phrase like end of last month into a schedule's parameter value and it is substituted as that text, letter for letter. The phrases above are settings on the flow's Date Picker tool, not values a schedule can pass. If a schedule supplies a value, that value is used exactly as typed; supplying an empty value is not the same as leaving the parameter out, either - an empty value substitutes nothing at all, where leaving the parameter out uses the flow's own moving default. When you want the date to move, set it on the Date Picker tool and let the schedule stay silent about it.

Delivery

Refreshing a dashboard makes it current. Delivering it puts it where people are.

On a dashboard step, set Then deliver it as to A single file anyone can open, and give a folder or a file path under To this folder or file. After the tables are refreshed, the whole dashboard - its pages, its visuals and the data behind them - is written out as one HTML file.

• Give a folder (\\server\reports) and the file is named after the dashboard, so Sales EMEA becomes Sales EMEA.html in that folder. The name is reduced to letters, digits, spaces, underscores and hyphens, so a dashboard called Sales / EMEA delivers as Sales EMEA.
• Give a file path ending in .html and that exact file is written.
• Folders that do not exist are created.
• The file is overwritten every run. That is deliberate: the path stays the same, so a link somebody has bookmarked or pinned in Teams keeps working and always holds this morning's numbers. If you want a copy per day, put the date in the path with a parameter on a flow step that writes it, rather than expecting the delivery to keep an archive.

What the recipient gets is a file, not a licence. It opens in any browser on any machine, offline, with nothing installed. Filters, cross-filtering and drill still work, because the engine that draws it travels inside the file. They cannot edit the dashboard, which is usually the point.

Two ways delivery can refuse, both on purpose. A dashboard built against a design sample of a large table will not be delivered, because a sample must never reach somebody who has no way of knowing it is one. And a dashboard that uses a table which is no longer registered fails rather than delivering a file with holes in it.

Delivering a diagram

A diagram step has the same two fields and three formats to choose between. All three are written by the same code the app's File then Export uses, with no browser anywhere near it.

Because SVG and PDF are one file per page, those two need a folder rather than a file. Give a file path anyway and the folder it sits in is used, which is almost certainly what was meant.

PNG and the other pictures are not offered, and a schedule that asks for one is refused before it is saved. Every picture format is drawn by a browser - the app starts a headless one to do it - and a scheduled run has no window to draw in. The refusal happens in the editor, in daylight, rather than at three in the morning. SVG is a picture too, and a better one for most uses: it is sharp at any size, it opens in every browser, and Word, PowerPoint and Confluence all take it. When you need a PNG specifically, export one by hand from Diagrams.

The refreshed diagram is also saved back to its own file whether or not it is delivered, so the copy in your Diagrams folder is the one the schedule saw. If you want the file left alone, deliver a copy and keep the source somewhere the schedule does not point at.

Run now

Run now runs the schedule immediately, in the app, whatever its trigger says. Use it for three things: proving a new schedule works before trusting it to the clock, re-running the one that failed overnight once you have fixed the cause, and running an on-demand schedule that has no trigger at all.

• It ignores the trigger completely. A folder-triggered schedule run by hand runs whether or not the folder has changed, and does not disturb what the poll has already seen.
• It ignores Switched on. A schedule you have switched off can still be run by hand, which is what makes switching off a safe way to pause something.
• It is refused while anything else is running in the app, with a message saying so.
• The row appears under Recent runs when the run finishes, not when it starts. The schedule's own row says running now in the meantime. A long run looks quiet until it is done, and a run started by Windows in its own process does not say running now at all - it simply appears in the history when it has finished.

Switching a schedule off

Untick Switched on and save. The schedule keeps its name, its steps, its trigger and its history, and its Windows task is removed, so nothing fires. Tick it again and the task comes back.

This is the right way to pause something for a fortnight while a source system is being migrated. Delete is for a schedule you are finished with: it removes the schedule and its task, and leaves the history rows it has already written, so last month's evidence does not disappear with it.

If a schedule is switched off and a task somehow fires anyway, the run is recorded as skipped with the reason, rather than silently doing nothing.

The run history

Every run writes one row, including the ones that did nothing. Three results:

The history is a CSV file, and that is a feature rather than an implementation detail. It can be loaded into Dashboards like any other file, which means the answer to "is everything still running" can be a dashboard you build once - runs by day, failures by schedule, the average duration creeping up - instead of an admin console somebody has to write. The file is appended to only by the runner, so it is safe to read while it is being written.

The newest 2,000 runs are kept. Older rows are trimmed, and the detail file of each trimmed run goes with it.

One run in detail

Click a schedule's name under Recent runs and you get that run, step by step: what each step was, whether it finished, how long it took, and either what it did or what went wrong. When a flow fails, the detail names the tool that failed - not just "the flow failed" but the label of the node, so you can open the flow and go straight to it.

Everything on that screen also exists as a file, one per run, which is useful when somebody asks what happened three weeks ago and you would rather grep than click.

History reference

Generated from the log itself, so a column that appears in the file appears here.

What is recorded for every run

One row per run, oldest first, newest 2,000 kept.

What is recorded for every step of a run

This is what the run detail screen shows, and what the detail file holds.

Failure notification

Something that runs unattended has to be able to say when it did not work. Schedules answers that without owning any mail code of its own.

Under When it fails, run this flow, choose one of your flows. When a run fails, that flow is run, and it is handed these parameters:

The tool to put in that flow is Send Email, in the Developer category: send an email for each record, optionally attaching a file the flow produced.

The Send Email tool does not send anything until you untick Do not actually send. It is ticked when you drop the tool on the canvas, on purpose: sending is the one thing in the palette that running the flow again cannot undo, so it rehearses until you say otherwise. A notifier that has never had that box unticked will report a failure perfectly and post nothing.

Inside that flow, put those parameters in the subject and the body. That is how a failure gets emailed. It is also how a failure gets written to a log table, posted to a webhook, or appended to a spreadsheet somebody reads on a Monday, because it is an ordinary flow and can do any of those.

Doing it this way is a decision rather than an omission. Schedules holds no mail server settings, no mailbox password and no OAuth tokens, because the flow engine already has a tool that sends mail and one implementation is better than two.

The shape of a notifier flow. The Send Email tool sends one message per record, and takes the address from a field, so the flow needs a row to send. The smallest one that works is three tools:

1. Enter Data with one row and one column, To, holding the address to write to.
2. Formula (optional) building the message from the parameters, if you would rather not put them straight in the subject and the body.
3. Send Email, with the mail server settings, To as the field holding the address, and a subject like Nightly job failed: $Job and a body holding $Error, $Run and $Started.

A value you type on a schedule is saved in the schedule file as plain text. That is fine for a month or a region and wrong for a mailbox password. An unattended run has nobody to type a password at, so the honest options are a mail relay that accepts no sign-in, or an account whose password you are content to have sitting in a file in your Documents folder. Encrypted stored credentials are a stage two feature and are not in this version.

Three things to know about the notifier:

• It is not itself a run in the history. It does not get a row, and nothing in the app reports on it.
• Its own failure is swallowed. If the notifier breaks, the failed run is still recorded correctly. Losing the record of the failure because the alarm was broken would be the worse outcome of the two.
• Which means you must test it by hand. Build it in Data Flow, give the four parameters sensible defaults, press Run, and check the mail arrives. Then nominate it.

What Windows sees

Every schedule that is switched on and has a clock or folder trigger becomes a task in Task Scheduler, under a folder of its own. Open Task Scheduler and you will find them there, named after the schedule with its id in brackets, so the folder reads like the list in the app and a renamed schedule can still be matched to the task it already had.

The name in brackets is the schedule's id, which is how a task is matched to its schedule after you have renamed it.

The task runs a small launcher with the windowless interpreter that ships with the app, which is why nothing appears on screen when a schedule fires. It runs as you, under your own account, with no stored password and no elevation - which is exactly why it only runs while you are signed in.

You do not have to touch Task Scheduler, and you should not need to. It is worth knowing it is there for two reasons: it is where you look when a schedule is not firing and you want to know whether Windows even has it, and its Last Run Result column is honest - the runner exits 0 when the job succeeded or had nothing to do, and 1 when it failed.

Where everything lives

Your schedules are your files. They sit under Documents, in the same place as your flows and your dashboards, so they are backed up by whatever backs those up, and copying one to another machine is copying a file. Everything derived - the history, and what the folder triggers have already seen - lives under Local AppData, because it can be rebuilt and does not belong in your documents.

Documents is yours; Local AppData is derived. Back up the first and you have kept your schedules. Lose the second and you have lost the history, which is a shame rather than a disaster.

The schedule file itself is plain JSON: what to run, with which values, on what trigger, and where the output goes. That is what makes a schedule diffable, copyable and reviewable, and it is the same philosophy as a saved flow or a saved dashboard.

Uninstalling, reinstalling and repair

Uninstalling removes every Windows task. It has to: a task pointing at a program that is no longer installed would fail every night for ever, and quietly fill somebody's Task Scheduler with red.

Your schedules survive, because they are files in your Documents folder and the uninstaller does not touch what you made.

They are repaired automatically. The first time you open the Schedules page after installing again, every switched-on schedule that has lost its task is given one back, in the background, while you are reading the list. The same repair covers a rebuilt machine and schedule files copied from another one: put the files in the Schedules folder, open the page, and the triggers appear.

Two things to check after a reinstall or a move. Schedules that point at flows by a full path to another machine's drive letter will need that path to exist. And the run history under Local AppData is not restored by copying schedule files, so a rebuilt machine starts its history again.

Troubleshooting

Nothing ran overnight. Was the machine on, and were you still signed in to Windows? Signing out stops everything. Then check Task Scheduler for the task, and the run history for a row: no row at all means the task never started, a skipped row means it started and had nothing to do.

"The schedule is saved, but Windows would not take the trigger". Windows refused to create the task and the message is quoted underneath. The schedule itself is saved. Reopen it, press Save again, and if it still refuses, the message is the thing to chase - it is Windows talking, not the app.

A flow step says the flow is not where the schedule says it is. The flow was renamed, moved or deleted after the schedule was made. A flow named without a path is looked for in your Workflows folder; edit the schedule and choose it again.

A diagram step says a data source could not be reached. The file the diagram is linked to is not where it was - moved, renamed, or on a share that is offline at that hour. The message names the source and the path it looked at. Fix the path in the diagram's Sources sheet, or run the flow that writes that file in an earlier step of the same schedule.

A diagram step says a source is a file picked in the browser. The diagram was linked to a file chosen in a file dialog rather than by path, so all it stored was the name. Open the diagram, remove that source and add the same file by its path, and the schedule can read it.

A dashboard step says a table is no longer registered. The dashboard uses a table that has been removed from Dashboards. Open the dashboard, load the table again, and the schedule will find it.

A delivered file has not appeared. Look at the run's error. The usual causes are a share that is offline, a folder you can read but not write to, and a path typed with a single backslash at the front of a UNC name.

The delivery is refused because of a sample. The dashboard is built against a design sample of a large table. Switch the dataset back to the full table in Dashboards before delivering it.

The history is full of skipped rows. A folder trigger checking every few minutes writes one row per check. Lengthen the interval, or accept it - the history keeps the newest 2,000 rows and trims the rest.

A run is taking longer than it should. The row only appears when the run finishes, so a run in progress looks like silence. The schedule's row shows running now for a run started in the app; one started by Windows shows nothing until it lands in the history.

A parameter value came out as literal text. Values are substituted exactly as typed. If you wanted a moving date, set it on the flow's Date Picker tool and leave the parameter out of the schedule altogether. See Relative dates.

The failure email never arrives. The notifier flow's own failure is deliberately silent. Open it in Data Flow and run it by hand, with the four parameters filled in, to see what it says.

"Something is already running." Only one run at a time is allowed in the app. Wait for the current one, or look at Recent runs to see what finished.

Something failed and there is no row at all. A failure that escapes the runner entirely is written to the engine log under Local AppData. It is the last place to look, and it is rarely needed.

Glossary