> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Validate schedules in CI

Add `tessl schedule validate` to your CI workflow to catch errors in the
`schedules` block of `tessl.json` before a change is merged. This is a manual
setup: add the step to your own CI configuration.

## What it checks

The command reads `tessl.json` and validates the file. It checks:

- The shape of the `schedules` block and each schedule entry.
- That every action a schedule names, directly or with `use`, is declared in
  the `actions` block.
- The `actions` block itself: each declaration's fields and values, and its
  name. A problem there is reported against the action, as in
  `actions.pr-report`.
- Schedule field names, including required fields, the rule that an entry's
  action fields go inside `action`, and the rule that each entry uses either
  `cron` or `schedule`, but not both.
- Field types, including structured schedule values and string-only input
  values.
- Cron syntax and supported human-readable or structured schedule forms.
- The minimum interval between runs, which is five minutes.
- That each repo-local `file:` skill exists in the working tree.

The command reports every problem it finds and exits with a non-zero status
when the file is invalid. CI uses that status to fail the check.

## What it does not check

Without a Tessl login, as in the workflow below, this command validates the
file only. It does not check server-side resources or workspace limits,
including:

- Whether the named environment exists or contains the required secrets.
- Whether the referenced skill or plugin is installed and available to the
  workspace.
- Whether the workspace has capacity for another active schedule.

Tessl checks those when the file syncs or when a run starts. Signed in, with a
`name` that identifies your project, the command runs them too. See
[Validate before you push](/schedules/overview.md#validate-before-you-push).

## GitHub Actions

The following workflow installs the Tessl CLI and runs the validator on pull
requests that change `tessl.json`:

```yaml
name: Validate Tessl schedules

on:
  pull_request:
    paths:
      - tessl.json
      - .github/workflows/validate-tessl-schedules.yml

jobs:
  validate-schedules:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Tessl CLI
        uses: tesslio/setup-tessl@v2
      - name: Validate Tessl schedules
        run: tessl schedule validate
```

The validation step does not need a Tessl token because it checks the local
file. The CLI's non-zero exit status fails the GitHub Actions job when a
schedule is invalid.

## File checks and server checks

This check catches file-level issues before merge, such as a misspelled field,
an invalid cron expression, or a schedule that runs too often. After a valid
file is merged and synced, Tessl performs server-side checks. For example, a
schedule whose environment doesn't exist still syncs, but its runs don't start
until you create the environment.

For the full schedule format, see [Schedules](/schedules/overview.md).