# `schedules.no_tick`

A schedule was run by hand against a deployment, and no tick of the app picked the run up in time, so nothing ran.

Area 14, [Tools](/docs/tooling.md); not declinable; the next step is usually the human's.

## Why Jadpo refuses it

Against a deployment's database, `jadpo schedules run` runs nothing
itself. It writes a request on the schedule's state row and waits for
the app's own tick to run it, so the deployment's settings and secrets
never leave its servers. A tick comes every period the app ticks at,
while the app runs; when none takes the request within twice that, the
command takes the request back and stops. Otherwise the run would happen
whenever the app next starts, perhaps much later.

Jadpo won't run the schedule on your machine instead: that would need
the deployment's settings and secrets, and would run beside its own
instances. Whether the app should be running, and where, only you know.

## What it looks like

A project whose `heartbeat` runs every second, so the app ticks every
second:




domains/health/schedules/heartbeat.jadpo:

```jadpo
use health/actions { beat }

/// Shows the app is ticking, every second.
schedule heartbeat {
    every: 1s
    run: beat()
}
```

`jadpo schedules run` against a database the migrations are applied to,
with no app running against it:

```sh
jadpo migrate apply
jadpo schedules run heartbeat
```

```text
Applied 1 migration to `main`
    20261020T1400_initial  applied
error: No tick picked up `heartbeat`'s run
  reason: The app's own server runs it on its next tick, which comes every 1 s while the app runs; none came, so the request was taken back, and nothing ran.
  next: Check the app is running, then run `jadpo schedules run heartbeat` again (human)
  rule: schedules.no_tick
  help: https://jadpo.dev/docs/errors/schedules.no_tick
```

`(human)` at the end of the `next:` line tells your coding agent to stop
and ask you which fix you want, because the choice is yours to make: it
decides where the schedule runs.

## How to fix it

The question is whether the schedule should run on the deployment or on
your machine.

**If it should run on the deployment**, start the app there, then run it
again:

```sh
jadpo schedules run heartbeat
```

The app's next tick takes the request and runs `heartbeat`, and the
command shows how the run went.

**If it should run on your machine**, start `jadpo dev` in another
terminal, and run it against `jadpo dev`'s own database:

```sh
unset DATABASE_URL
jadpo schedules run heartbeat
```

The command runs `heartbeat` itself, straight away, and shows how the
run went.

## Related

- [Running a schedule by hand](/docs/what-an-operator-sees.md#running-a-schedule-by-hand)
- [The tick](/docs/schedules.md#the-tick)
- [`jadpo schedules`](/docs/commands-for-background-work.md#jadpo-schedules)