> ## Documentation Index
> Fetch the complete documentation index at: https://grow-hub.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Schedule a post

> Queue a post for later, change your mind, and recover failures.

Studio runs its own scheduler rather than handing posts to a platform's native
one, so a single system knows what is pending.

## Schedule it

```text theme={null}
Schedule that draft for Tuesday at 9am Berlin time.
```

The assistant calls `schedule_post` with an ISO 8601 timestamp that includes an
offset:

```json theme={null}
{
  "id": "6f0c…",
  "scheduledAt": "2026-09-01T09:00:00+02:00"
}
```

Studio checks up front that the time is in the future, the target platform is
connected, and the content fits that platform's limit — you find out now, not at
2am when it fires.

<Tip>
  Always send an offset (`+02:00`) or a `Z`. A bare local timestamp is ambiguous
  and will be rejected or land in the wrong hour.
</Tip>

## Verify

```text theme={null}
Show me everything scheduled.
```

`list_posts` with `status: "scheduled"` returns each post with its `scheduledAt`
and the resolved `scheduledPlatform`.

## Edit while it waits

Content edits are safe on a scheduled post — the new text is re-checked against
the platform it is aimed at:

```text theme={null}
Change the second sentence of the Tuesday post.
```

Changing **which platforms** it targets is draft-only. Unschedule first:

```text theme={null}
Unschedule it, retarget it to X, and schedule it for the same time.
```

## Move or cancel

| Want             | Ask for                                      |
| ---------------- | -------------------------------------------- |
| A different time | `schedule_post` again with the new timestamp |
| Back to a draft  | `unschedule_post`                            |
| Gone entirely    | `unschedule_post`, then `delete_draft`       |

## When it fires

A cron tick runs every minute, so posts go out within roughly two minutes of the
target time. Dispatch re-validates everything against the database, then
publishes through the same path as `publish_post`.

If it fails, the post lands in `failed` with a `failureReason`:

```text theme={null}
Why did my Tuesday post fail?
```

Permanent problems — a revoked connection, an expired token, a platform
rejection — fail on the first attempt. Transient ones (rate limits, platform
outages) retry with exponential backoff up to five times.

Fix the cause, then re-schedule the failed post directly — no need to unschedule
it first:

```text theme={null}
Reconnect LinkedIn, then reschedule that post for tomorrow at 9am.
```