Troubleshoot Scheduled Workflows

Troubleshoot Scheduled Workflows

A scheduled workflow can fail before it starts, while it is running, or after it reaches an output.

The problem may involve:

• the schedule;
• the computer;
• Feluda;
• the selected workflow;
• an AI provider;
• a local model;
• a Gene or tool;
• the source information;
• an overlapping run; or
• the destination where the result should be saved.

Troubleshoot one layer at a time.

Begin by deciding whether the workflow did not start or started and failed.

First identify the type of problem

Use the recent run history and next-run information in Schedule Manager.

Problem	What to check first
No run appears	Schedule status, next-run time, Feluda availability, and computer state
Run started but failed	Error message, first failing step, provider, model, or tool
Run completed with bad output	Input, workflow path, model instruction, and source
Wrong time	Date, recurrence, timezone, and daylight-saving changes
Duplicate output	Duplicate schedules, overlaps, retries, and shared destinations
Result missing from destination	Tool action, permissions, file path, Journal, or connected service

This distinction prevents unnecessary changes to a workflow that never started.

Open Schedule Manager

Open RunFlows, then open Schedule Manager.

Review:

• the schedule name;
• the selected workflow;
• whether the schedule is active or paused;
• the recurrence;
• the time and timezone;
• the next planned run;
• recent history;
• warnings;
• conflicts; and
• the latest execution result.

Confirm that you are investigating the correct schedule.

If the scheduled run did not start

Check whether:

• the schedule was active;
• the next-run time was correct;
• Feluda was available;
• the computer was on and awake;
• the schedule had already been changed;
• the selected time had passed in the configured timezone;
• another schedule conflict prevented normal execution; and
• the workflow was still available.

A missing run record usually means the trigger itself did not begin.

Check whether the schedule is paused

A paused schedule remains saved but does not start future runs.

Confirm the current state.

If the schedule should be active:

1. review its workflow and settings;
2. test the workflow manually;
3. confirm the next-run time;
4. resolve any warning or conflict; and
5. resume the schedule.

Do not resume only because a run was missed.

First confirm why it was paused.

Check the next-run date and time

Review the displayed next planned run.

Check:

• the calendar date;
• the weekday;
• the time;
• the timezone;
• the recurrence pattern; and
• whether the next run moved after an edit.

A weekly schedule may be set to the wrong weekday.

A monthly schedule may use a day that does not occur in every month.

A one-time schedule may already have passed.

Check the timezone

A schedule may appear early or late when the timezone is incorrect.

Review the timezone after:

• travel;
• moving the computer;
• a daylight-saving change;
• changing the intended audience location; or
• importing or recreating a schedule.

Do not judge the schedule only by the written clock time.

Confirm the full next-run date and time shown by Feluda.

Check daylight-saving changes

A recurring schedule may shift relative to another region when daylight saving begins or ends.

Review:

• the configured timezone;
• the next planned run;
• the local computer time;
• the time expected by the reviewer; and
• any connected service that uses another timezone.

Update the schedule when the intended real-world time has changed.

Check whether Feluda was available

Scheduled desktop execution depends on Feluda being available.

Confirm whether:

• the application was open;
• the computer was on;
• the user session was active;
• the computer was asleep;
• the application closed unexpectedly; or
• the operating system restarted.

For important schedules, keep Feluda running and configure the computer so it remains available during the planned execution window.

Check sleep and power settings

A computer that enters sleep may not start the workflow at the expected time.

Review:

• sleep settings;
• laptop lid behaviour;
• battery-saving settings;
• automatic shutdown;
• scheduled operating-system restarts; and
• whether the device was disconnected from power.

Test a near-future one-time schedule after changing power settings.

Check whether the workflow still exists

A schedule may point to a workflow that was:

• renamed;
• removed;
• replaced;
• changed significantly;
• disconnected from a required Gene; or
• left in an invalid state.

Open the workflow in Studio.

Confirm that it:

• loads correctly;
• has a valid starting path;
• contains an intentional endpoint;
• has no blocking validation issue; and
• still matches the schedule's starting input.

Run the workflow manually

Manual execution is the most useful troubleshooting step.

Open RunFlows and run the same saved workflow with the scheduled input.

If the manual run fails, the problem is likely in:

• the workflow;
• the provider;
• the model;
• the tool;
• the source; or
• the destination.

If the manual run succeeds, review the schedule timing, desktop availability, and trigger configuration.

Use the exact scheduled input

Test the same input stored in the schedule.

A manually typed message may work while the saved scheduled input is:

• incomplete;
• outdated;
• too vague;
• too long;
• missing a required source;
• using an old format; or
• asking for a tool that is no longer available.

Copy the scheduled input into a manual run and compare the result.

If the workflow started but failed

Open the failed run and read:

• the status;
• the full error;
• intermediate output;
• warnings;
• tool activity; and
• the last successful step.

Find the first block that did not return the expected result.

Do not begin by changing the final Output block.

If the cloud provider failed

Check:

• the internet connection;
• provider configuration;
• the API key;
• access to the selected model;
• provider service availability;
• input size;
• timeout behaviour; and
• whether the account can complete the request.

Test the same model in Workbench.

If Workbench fails too, correct the provider setup before changing the schedule.

If the local model failed

Confirm that:

• Ollama, LM Studio, or the selected local runner was open;
• its server was running;
• the configured address and port were correct;
• the required model was downloaded;
• the model was loaded when necessary;
• enough memory was available; and
• another local workflow was not consuming the available resources.

Test the model in Workbench.

Use a smaller model or reduce overlapping runs when the computer becomes slow or unstable.

If the local model was not running at the scheduled time

A local provider can work manually and still fail on schedule when its service is closed later.

Confirm how the local model application starts.

For important schedules:

• open the model runner before the run;
• confirm its service is active;
• load the required model;
• avoid closing it after testing; and
• check the local endpoint shortly before the first scheduled run.

The schedule cannot start the local model application unless the workflow and environment are specifically prepared for that behaviour.

If a Gene or tool failed

Review whether:

• the Gene remains installed;
• it has been synced;
• the expected tool is still included;
• required settings are complete;
• a connected account is active;
• the tool has the required permissions;
• the external service is available; and
• the workflow passes the correct information.

Test the tool in Workbench with a small, safe request.

If a permission error appears

A tool may be blocked because the requested action falls outside its allowed access.

Review the workflow permissions and any relevant:

• URL rules;
• IP rules;
• file-path rules;
• port rules;
• service permissions; or
• account permissions.

Do not expand access automatically.

First confirm that the requested destination or source is correct and necessary.

If the source was unavailable

A scheduled workflow may depend on a file, service, website, Journal entry, or connected source.

Check whether the source:

• existed at run time;
• used the expected location;
• contained new information;
• was accessible;
• required authentication;
• changed its format; or
• returned an empty result.

A schedule cannot create source information that was not available.

If a file was missing

Confirm:

• the exact file path;
• the filename;
• whether the file was moved;
• whether a network drive was connected;
• whether the user account had access;
• whether the file existed before the trigger; and
• whether another process renamed or removed it.

Use stable file locations for scheduled workflows.

Avoid temporary download folders when the file may disappear before the run.

If the Journal result is missing

Check:

• whether the Journal tool was called;
• the journal or destination selected;
• the entry title;
• tool permissions;
• whether the workflow failed before the write step;
• whether the entry was created under an unexpected name; and
• whether another run created a duplicate.

Search the Journal by title or date.

Confirm the destination before retrying the run.

If the wrong destination was used

Pause the schedule.

Review:

• the selected tool;
• file paths;
• journal names;
• record identifiers;
• account selection;
• message recipients;
• output titles; and
• values passed from earlier blocks.

Test the corrected destination manually with non-sensitive information.

Resume only after confirming the result in the intended location.

If the run timed out

A timeout may be caused by:

• a slow provider;
• a large local model;
• limited memory;
• a long input;
• several AI blocks;
• an unavailable tool;
• a slow external source; or
• a runtime limit that is too short.

Compare the maximum runtime with successful manual runs.

Increase the limit only when normal execution genuinely needs more time.

Do not use a longer limit to hide an unavailable service or broken step.

If the workflow overlaps with itself

A recurring schedule may start again before the earlier run finishes.

This can create:

• duplicate output;
• competing model requests;
• repeated writes;
• overwritten files;
• conflicting updates; or
• confusing history.

Review:

• recurrence frequency;
• normal runtime;
• slowest observed runtime;
• maximum runtime; and
• next-run spacing.

Increase the interval or simplify the workflow.

If two schedules conflict

Conflict may occur when two schedules:

• start at the same time;
• use large local models;
• access the same file;
• update the same record;
• write the same Journal title;
• use the same limited service; or
• compete for the same output destination.

Resolve the conflict by changing timing, separating destinations, or running one workflow manually.

If duplicate output appears

Check for:

• duplicate schedules;
• repeated manual retries;
• overlapping runs;
• identical output names;
• two workflows writing to the same destination; and
• a delayed confirmation from an earlier run.

Pause the related schedules before investigating.

Remove duplicate schedules only after confirming which configuration should remain.

If a missed run is evaluated later

A pending schedule may be evaluated when Feluda becomes available again, depending on its cadence and current state.

Review the recent history before manually replacing a missed run.

Otherwise, you may create a duplicate result.

Confirm:

• whether a delayed execution already started;
• whether the result still matters;
• whether the source is still valid;
• whether another schedule produced the output; and
• whether the destination already contains an item.

If the output is inaccurate

A schedule can start correctly while the workflow produces a poor result.

Review:

• the exact scheduled input;
• source content;
• selected model;
• AI instructions;
• extraction fields;
• classification labels;
• tool output;
• branch selection; and
• final formatting.

Test the same example manually and find the first incorrect intermediate result.

If the wrong branch ran

For an LLM Label block, check:

• label names;
• label descriptions;
• overlapping categories;
• the fallback path;
• unusual source wording; and
• whether the selected model classifies consistently.

For an Expression block, check:

• the incoming value;
• spelling;
• capitalisation;
• date and number formats;
• missing values; and
• the comparison rule.

Test every branch before restoring the schedule.

If the result is empty

Trace the workflow from its starting input to its final Output block.

Check whether:

• the scheduled input was empty;
• the source returned no information;
• an early block returned an empty value;
• the wrong path was followed;
• a tool returned no result;
• an Output block was not reached; or
• an error path did not return a visible message.

Add intermediate output where needed to make the failure easier to see.

If warnings repeat

Repeated warnings should be treated as a workflow or schedule problem.

They may indicate:

• missing source fields;
• unreliable input;
• a fallback path being used too often;
• incomplete tool results;
• recurring conflicts;
• a model that does not follow the instruction; or
• output that always requires correction.

Pause the schedule when repeated warnings affect trust in the result.

If the computer is overloaded

Several scheduled local workflows can use too much memory or processing power.

Signs include:

• very slow responses;
• models failing to load;
• timeouts;
• the application becoming unresponsive;
• system instability; or
• runs finishing much later than expected.

Reduce simultaneous runs, use smaller models, change the schedule times, or close unnecessary applications.

If the workflow works manually but not on schedule

Compare the manual and scheduled environments.

Check whether:

• the same input was used;
• the same workflow version ran;
• the provider was available at the scheduled time;
• local services were running;
• the source existed at that time;
• the computer was awake;
• the schedule used the correct timezone; and
• another run caused a conflict.

The workflow may be correct while the scheduled environment is incomplete.

Pause before making major changes

Pause the schedule before changing:

• the workflow;
• the provider;
• the model;
• the source;
• the tool;
• the destination;
• the recurrence;
• the timezone; or
• the runtime limit.

Test the changed workflow manually.

Resume only after confirming the next-run time and result destination.

Use a one-time schedule for recovery testing

After correcting a schedule, create or use a one-time test run with non-sensitive input.

Confirm that:

• the trigger starts;
• Feluda is available;
• providers and tools work;
• the result reaches the intended destination;
• the run history records the outcome; and
• no duplicate action occurs.

Then restore the intended recurring schedule.

Decide whether to rerun a missed task

Before manually rerunning, ask:

• Is the result still useful?
• Is the source still current?
• Could a late result cause confusion?
• Has another run already produced it?
• Could the retry duplicate a write action?
• Is a reviewer available?
• Should the output title include the original or current date?

Not every missed schedule needs to be recreated.

Know when to stop retrying

Stop and investigate when:

• the cause remains unclear;
• a write action may already have completed;
• the wrong destination was used;
• the same error repeats;
• the computer is unstable;
• a connected service is unavailable;
• sensitive information may be sent incorrectly; or
• the result cannot be reviewed.

Repeated retries can create additional errors and duplicates.

A practical troubleshooting routine

Use this process:

1. Open Schedule Manager.
2. Confirm the schedule is active.
3. Check the next-run date, time, and timezone.
4. Review recent history.
5. Decide whether the run was missed or failed.
6. Confirm Feluda and the computer were available.
7. Run the workflow manually with the exact scheduled input.
8. Test the provider, local model, and tools.
9. Find the first failing step.
10. Check overlap and destination conflicts.
11. Pause the schedule before major changes.
12. Correct one issue.
13. Test with a one-time or manual run.
14. Confirm the next planned run.
15. Resume only after the result is dependable.

This approach separates trigger problems from workflow problems and keeps corrective actions controlled.