osFoundry / Platform
App cron jobs
Schedule recurring tasks per app. Cron syntax, retries, observable runs.
What it is
App cron jobs let you schedule recurring work for a specific app inside osFoundry. Instead of leaving a script running or remembering to trigger something by hand, you attach a schedule to the app itself and let it run on its own cadence. Each job is defined with standard cron syntax, so an expression like `0 * * * *` runs hourly and `30 6 * * 1-5` runs at 6:30 on weekdays. Because the schedule belongs to the app, everything the job needs — its logic, its environment, its keys — travels with the app rather than living in a separate, disconnected scheduler.
Under the hood, each scheduled run is treated as an observable unit. When a run fails, the job retries rather than silently dropping the work, and every attempt is recorded so you can see what ran, when it ran, whether it succeeded, and what it produced. That run history is the difference between a cron line you hope is firing and a schedule you can actually verify. osFoundry is a bring-your-own-key desktop workspace, so these jobs execute against the models and services you connect with your own API keys — there is no reseller markup on what a recurring job costs you, and because the workspace is local-first, the app and its schedule can live on your own device instead of a vendor's servers.
This matters most for the quiet, repetitive work that apps accumulate: pulling in data on a cadence, regenerating an output, running a check, kicking off an agent task on a timer. Cron gives you precise control over when, retries make the schedule resilient to a transient failure, and the run log makes the whole thing auditable. It sits alongside the rest of osFoundry — chat and agents, apps, code, knowledge and data — so a scheduled app job can feed the same workspace you already work in rather than a separate automation silo.
Key capabilities
- Define schedules with standard cron syntax, from a simple hourly tick to weekday-only or month-boundary expressions
- Attach the schedule to a specific app so its logic, environment, and keys run together as one unit
- Automatic retries on a failed run instead of silently dropping the scheduled work
- Observable run history: see each run's time, status, and output to confirm the schedule actually fired
- BYOK and local-first — jobs run against your own connected models and keys, with no per-seat fees or reseller markup
Use cases
- Data engineer: schedule an app to pull and refresh a dataset every hour with cron, and check the run log to confirm each sync completed
- Operations lead: run a weekday-morning app job that regenerates a report and retries automatically if the source is briefly unavailable
- Solo builder: put a recurring agent task on a nightly cron so routine work runs unattended on your own machine, against your own API keys
Frequently asked questions
What cron syntax does osFoundry use?
Standard cron expressions — five fields for minute, hour, day of month, month, and day of week. So `0 * * * *` runs at the top of every hour and `30 6 * * 1-5` runs at 6:30 on weekdays. The schedule is set per app.
What happens if a scheduled run fails?
The job retries rather than silently dropping the work, and every attempt is recorded in the app's run history so you can see which runs succeeded, which failed, and what each one produced.
Where do the jobs run, and what do they cost?
osFoundry is a local-first, bring-your-own-key desktop workspace, so a scheduled app job runs against the models and services you connect with your own API keys. There is no reseller markup on that usage and no per-seat fee for scheduling.