> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testorim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations overview

> Where Testorim connects to the rest of your toolchain.

<CardGroup cols={2}>
  <Card title="GitHub" icon="github" href="/integrations/github">
    Run your tests on every pull request and get one sticky comment with the
    results.
  </Card>

  <Card title="Slack" icon="slack" href="/integrations/slack">
    Failure alerts to a channel you pick.
  </Card>

  <Card title="Email" icon="mail" href="/integrations/email-alerts">
    Failure alerts to a list of recipients.
  </Card>

  <Card title="CLI and API" icon="terminal" href="/developers/platform-overview">
    Trigger runs from any pipeline with an API key.
  </Card>
</CardGroup>

## Which one you want

| You want                                           | Use                                                                 |
| -------------------------------------------------- | ------------------------------------------------------------------- |
| Tests on every pull request, results in the PR     | [GitHub](/integrations/github)                                      |
| To be told when a nightly run breaks               | [Slack](/integrations/slack) or [email](/integrations/email-alerts) |
| Tests in a pipeline that is not GitHub             | [The CLI](/developers/cli)                                          |
| Tests on a schedule with no pipeline at all        | Project settings → Schedules                                        |
| To send a result to a colleague without an account | A [share link](/test-execution/evidence#where-to-find-it-all)       |

<Note>
  Testorim does not send outbound webhooks. To react to a run programmatically,
  trigger it yourself with the [API](/api-reference/introduction) or the
  [CLI](/developers/cli) and read the result. The CLI's exit code is 0 on
  pass, 1 on fail, 2 on error, which is usually all a pipeline needs.
</Note>

## Alert behaviour

Slack and email alerts share the same rules.

* They fire on a **failed** run, and on a run whose performance status is
  `degraded`.
* They are **throttled**, so a broken site does not produce an alert storm.
* They are configured per project, in project settings → Alerts.
* They need a paid plan.

## Scheduled runs

Project settings → **Schedules** attaches a cron expression to a saved test.
The worker dispatches it server-side; **Run now** fires one immediately.

How many schedules you can have depends on your plan. If the workspace loses
access, an unpaid subscription for instance, schedules are disabled with
that reason and re-enabled automatically when it is resolved.


## Related topics

- [Platform overview](/developers/platform-overview.md)
- [API reference](/api-reference/introduction.md)
- [GitHub](/integrations/github.md)
- [Create a project](/getting-started/create-a-project.md)
- [Slack](/integrations/slack.md)