> For the complete documentation index, see [llms.txt](https://seekspeed.gitbook.io/seekspeed-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://seekspeed.gitbook.io/seekspeed-docs/regression-guard/scheduling.md).

# Scheduling & pg\_cron

Guard cadence is enforced by Postgres. A single `pg_cron` job pings a public HTTP endpoint every 5 minutes; the endpoint asks Postgres which schedules are due and executes them.

```
        pg_cron (every 5m)
             │
             ▼
   POST /api/public/hooks/guard-tick
             │
             ▼
   runDueGuards()  ─── SELECT * FROM guard_schedules
                       WHERE enabled AND next_run_at <= now()
                       LIMIT 25
             │
             ▼
   for each schedule:
     run benchmark set (1 iteration per prompt)
     compute summary
     if baseline + threshold breach → INSERT guard_alerts + POST webhook
     UPDATE next_run_at := now() + cadence
```

## Cadence semantics

| Cadence  | Interval   |
| -------- | ---------- |
| `15m`    | 15 minutes |
| `hourly` | 60 minutes |
| `daily`  | 24 hours   |
| `weekly` | 7 days     |

The tick period (5 min) is the minimum resolution. A `15m` schedule fires on the next tick after `next_run_at` — expect ±5 min jitter. That is acceptable for regression detection; if you need sub-minute cadence you want load testing, not Guard.

## Per-tick execution shape

Each due schedule runs the benchmark set **once per prompt, non-streaming, temperature 0.2**. This keeps the tick cheap and comparable across cadences:

```ts
// inside runDueGuards
const results = [];
for (const p of prompts) {
  const r = await callOnce({ baseUrl, apiKey, model, systemPrompt, prompt: p.text, maxTokens });
  results.push(r);
}
const summary = summarize(results);
```

If you need iteration counts high enough to make Welch's *t*-test meaningful, put ≥3 prompts in the set. The comparison uses the per-prompt total latencies as the sample; a 3-prompt set gives you `n=3` vs the baseline's captured totals array.

## Baseline sample size

When you pin a baseline, Guard stores the per-iteration `totalMs` array. That means a baseline pinned from a **30-iteration run** gives you `n=30` on the reference side, and every scheduled tick contributes `n=prompts.length` on the observed side. Pin your baselines off healthy, high-iteration runs.

## Recovery from broken schedules

If a schedule handler throws (bad endpoint, expired API key, deleted connector) the tick still bumps `next_run_at` so one broken schedule never hogs the tick. The row keeps its `enabled=true` state — Guard will keep trying until you fix or pause it.

## Cost implications

Every tick is real API traffic. A 5-prompt set on `15m` cadence = 480 requests/day. Multiply by iteration cost per your provider. For expensive closed-weight models, prefer `hourly` or `daily`; reserve `15m` for cheap self-hosted endpoints where p95 drift matters.

## Reference

* Tables: `guard_baselines`, `guard_schedules`, `guard_alerts`.
* Endpoint: `POST /api/public/hooks/guard-tick`, auth via Supabase `apikey` header.
* Cron job name: `seekspeed-guard-tick`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://seekspeed.gitbook.io/seekspeed-docs/regression-guard/scheduling.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.