# Running and scheduling

## Ways to start a run

| From | Press | Runs |
|---|---|---|
| A journey's page | **Run journey** | That journey, after any journeys it needs first. |
| A platform's page | **Run all** | Every journey on the platform, each as its own run. You can also tick some journeys and run just those. |
| A project's page | **Run everything** | Every journey on every platform of the project. |
| Your pipeline or a script | the [REST API](/docs/api) | Any journey or platform, with an API key. See [Running from CI](/docs/ci). |
| A schedule | nothing, it starts itself | What the schedule points at. |

A run walks the journey in a fresh browser or phone, judges each check where it was added, and records a video. Archived journeys are never run.

## How a run ends

| Result | Means | Charged |
|---|---|---|
| **Passed** | Every check held. | Yes |
| **Failed** | At least one check did not hold, or the run stopped before the end (see below). | Yes |
| **Error** | The run measured nothing: the browser or phone never came up, or something on our side broke. | No. The credits come back automatically. |

A failed run is a result, and usually the one you most needed, so it is charged like a pass. An error is our problem, not your app's, so it is never charged.

## Run limits

A run may take up to **10 minutes on a website or API** and **15 minutes on a phone**. A run that is still going then has almost always met an app that stopped answering. It stops before its next screen, keeps everything it measured and its video, and is reported as **failed**, with the screen it stopped at named on the run page and in the PDF.

A phone run also stops when the account's credits run out, in the same way.

Each account runs **two runs at once** (four on Monthly credits). More wait their turn, and nobody else's runs wait for yours.

## What a run costs

| Platform | Cost |
|---|---|
| Website | 1 credit a run |
| API | 1 credit a run |
| Android or iPhone | 1 credit per minute of phone time, at most 15 |
| Load test | 1 credit per 50 virtual-user-minutes |

The credits are taken when the run starts, so a queue of runs cannot spend more than you have. A phone run first holds what it expects to need, based on the last run of the same journey (10 minutes when there is no history), and gives back what it did not use when it finishes. Phone time is counted from when the phone is ready with your app installed, not while one is being found. The journey page shows what a run will cost before you press Run. See [Credits and billing](/docs/credits).

## Schedules

A schedule runs a journey, a whole platform, or an API flow under a load profile, by itself. Add one on the **Schedule** tab of a journey, or the **Schedules** tab of a platform.

**How often** is one of:

- **Hourly**, at a chosen number of minutes past the hour
- **Daily**, at a chosen time
- **Weekdays**, Monday to Friday at a chosen time
- **Weekly**, on a chosen day at a chosen time

Times are in the schedule's own time zone and stay right when the clocks change. Every plan can schedule. A scheduled run costs the same as one started by hand.

A schedule that comes due and cannot run says why on the schedule and on the dashboard, rather than quietly skipping:

- the previous run is still going, so this one is skipped to keep the two from measuring each other
- the account is out of credits
- BitAssure was down at that moment and the time passed more than an hour ago (missed runs are not piled up and run late)

**Schedules** in the sidebar lists every schedule in the account.

## Being told

A scheduled run emails the account's members when a journey **starts failing** and again when it **passes again**, never every night it stays the same. A schedule that could not run emails once. Each person can switch these emails off under **Settings → Your account → Mail me about scheduled runs**. Runs started by hand or from CI do not email; your pipeline already tells you.