> ## Documentation Index
> Fetch the complete documentation index at: https://docs.script.it/llms.txt
> Use this file to discover all available pages before exploring further.
# Triggers
> Triggers let your scripts run on their own — on a schedule, when something happens in a connected app, or when a webhook URL receives a request.
Triggers let your scripts run automatically — no need to open the app and start them by hand. You attach a trigger to a script, tell it what to watch for, and Script.it runs the script every time that thing happens.
## What a trigger can watch for
There's one kind of trigger, with a menu of things it can watch for:
* **A schedule** — every weekday at 8 AM, every six hours, the first of the month. See [Schedule triggers](/triggers/schedule).
* **An app event** — a new Notion database item, a GitHub pull request, a Slack mention, a Calendly booking, a new row in a Google Sheet. Over 80 events across 40+ apps. See [App events](/triggers/app-events).
* **A webhook** — your own URL that any service can send a request to. See [Webhook triggers](/triggers/webhook).
* **Anything else** — if nothing in the menu fits, the agent can build a custom trigger for you. See [Custom triggers](/triggers/custom).
They all behave the same way once they exist: they watch for something, and when they see it, they run your script.
## Creating a trigger
The easiest way is to ask the agent in chat:
> Run this every weekday morning at 8 AM.
> Trigger this whenever someone opens a pull request on our repo.
The agent picks the right trigger, fills in the settings, and switches it on.
You can also create one yourself: open the script, click the **Triggers** tab, and click **Add Trigger**. A searchable list shows every event available for the apps you've connected.
Either way, the trigger starts working as soon as it's created.
## What a trigger does
A trigger runs a script. You choose which script, and optionally the input values it should run with — the same inputs you'd fill in when running it by hand.
When the trigger fires, the details of what happened are handed to your script, so it can act on them — the contents of the Slack message, the fields on the new Notion item, the body of the webhook request.
Runs show up in your session history alongside sessions you started yourself. Related events can be grouped into a single ongoing session instead of opening a new one every time, so a busy trigger doesn't flood your history.
## Triggers are part of the script
A trigger isn't a separate thing hanging off your script — it lives inside it, like a block does:
* It appears **in the script**, with its own settings, an on/off switch, and its recent run history.
* It's saved with the script's files.
* So it **travels with the script**. Export the script, import it into another workspace, or share it with a teammate, and its triggers come along.
There's no separate place to keep in sync: change the trigger and the script updates with it.
## Triggers in a shared workspace
Scripts are shared with your workspace, but triggers run **for a person**. So when a teammate opens a shared script, its triggers appear switched **off**, with an **Enable** button.
Turning one on creates their own copy. It runs with their connected accounts and their credits, and it has its own settings and run history.
This is deliberate. A Gmail trigger your teammate enables watches *their* inbox, never yours — and nobody is signed up for someone else's automation just by opening a shared script.
Any member of the workspace can enable a script's triggers. Doing so doesn't change the script or affect anyone else's copy.
Deleting a trigger is a shared change: it removes the trigger from the script and removes **every member's** copy of it. Turning a trigger off only affects your own. See [Managing triggers](/triggers/managing).
## Next steps
Run a script on a recurring cadence.
React to activity in Slack, GitHub, Notion, and more.
Give your script a URL any service can call.
Run history, failures, pausing, and limits.