> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vizra.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Running from the Dashboard
> A Run button in the browser that executes on your infrastructure — via your scheduler, or your CI.
Suite pages have a **Run now** button. Pressing it does not run anything on our servers — we
have no access to your models, your keys or your data. It records a request, and something
you control picks it up.
The line under the button — *runner last seen 13 hours ago* — is how you know a request will
actually be collected. If it says the runner has never checked in, pressing Run will queue
something nothing is listening for.
## Path 1: your scheduler
The default, and the one to use if your app is deployed anywhere with a cron.
With a key configured, the package registers `evals:runner` on your scheduler for you —
every minute, `withoutOverlapping()`, riding the cron that already runs `schedule:run`. It
polls for requested runs, executes them locally and reports the results back.
Nothing to add. If you would rather register it yourself:
```bash .env theme={null}
VIZRA_CLOUD_AUTO_SCHEDULE=false
```
```php routes/console.php theme={null}
Schedule::command('evals:runner')->everyMinute()->withoutOverlapping();
```
This needs `vizra/evals` installed as a regular dependency rather than `--dev`, because the
runner has to exist in the deployed application.
## Path 2: CI dispatch
For teams whose evals only ever run in CI — no long-running app, nothing to schedule.
Connect a GitHub repository in the project's settings, and Run now triggers a
`workflow_dispatch` on a workflow you nominate. Your existing pipeline runs the suite with
its own secrets and reports through the same endpoint.
You supply four things: repository, workflow file, ref (branch or tag), and a token.
The token needs **Actions: write** on that one repository, and nothing else. Do *not* use a
classic token with the `repo` scope — that is write access to every repository the grantor
can see, handed to a third party, to press one button.
The workflow must accept `workflow_dispatch`:
```yaml .github/workflows/evals.yml theme={null}
on:
workflow_dispatch:
pull_request:
paths: ['app/Agents/**', 'evals/**']
```
### When dispatch fails
GitHub returns **404** for a missing repository, a missing workflow *and* a token without
permission — the same response for all three, deliberately, so a token cannot be used to
probe for private repositories. Unhelpful when it is your own repo, so Cloud spells out the
possibilities rather than passing the bare status through. Check, in order: the workflow
file exists on the ref you named, it declares `workflow_dispatch`, and the token has
Actions: write.
## Choosing
| | Use the scheduler | Use CI dispatch |
| ------------------------- | ----------------- | ------------------ |
| App deployed with a cron | ✓ | |
| Evals only ever run in CI | | ✓ |
| Wants results in seconds | ✓ (next minute) | (a pipeline start) |
| Nothing to configure | ✓ | needs a token |
Both are available on every plan. The run executes on your infrastructure either way.