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

# Configure actions

> Define and remotely execute custom action workflows in your installs.

Actions let you define and remotely execute custom workflows in installs. You can automate common tasks, implement healthchecks, and even automate runbooks to handle incidents.

For one-off scripts you don't want to commit to TOML, see [Run adhoc actions](/guides/adhoc-actions).

## Configuring action workflows

Action workflows can be configured in your app's TOML config. For example, to define an HTTP healthcheck:

```toml actions/http_healthcheck.toml theme={null}
# action
name    = "http_healthcheck"
timeout = "0m15s"

[[triggers]]
type          = "cron"
cron_schedule = "*/5 * * * *"

[[triggers]]
type = "manual"

[[steps]]
name    = "healthcheck"
command = "./healthcheck"

[steps.public_repo]
repo      = "nuonco/actions"
branch    = "main"
directory = "common"

[steps.env_vars]
ENDPOINT             = "https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}"
METHOD               = "HEAD"
EXPECTED_STATUS_CODE = "200"
```

```toml actions/<your-action>.toml theme={null}
# action
version      = "v1"
description  = "Your app on AWS."
display_name = "Your App"

[[actions]]
source = "./actions/alb_healthcheck.toml"
```

Once configured and synced, you will see the workflow in the "Actions" tab for your app.

Following that example, we can describe the parts of a workflow.

### Timeout

Each workflow must have a timeout limiting how long it can run. The maximum allowed timeout is 30 minutes. Timeouts must be provided as valid Golang `time.Duration` strings.

The example workflow will time out after 15 seconds, more than enough time to make a simple HTTP request.

### Action triggers

Action triggers are available for all workflows. You can use the following set of triggers:

* `pre-provision`
* `post-provision`
* `pre-reprovision`
* `post-reprovision`
* `pre-deprovision`
* `post-deprovision`
* `pre-deploy-all-components`
* `post-deploy-all-components`
* `pre-teardown-all-components`
* `post-teardown-all-components`
* `pre-deprovision-sandbox`
* `post-deprovision-sandbox`
* `pre-reprovision-sandbox`
* `post-reprovision-sandbox`
* `pre-update-inputs`
* `post-update-inputs`
* `pre-secrets-sync`
* `post-secrets-sync`
* `role-enabled`
* `role-disabled`

Each workflow trigger is called at the beginning or end of the workflow. In some cases, such as `pre-provision` or `pre-reprovision` that include a stack-run, the trigger will be called right after the runner is healthy.

#### Role change triggers

The `role-enabled` and `role-disabled` triggers fire when a customer enables or disables an [operation role](/concepts/operation-roles) in their install stack. Use these to run validation, auditing, or setup tasks whenever elevated permissions are granted or revoked.

```toml actions/role_audit.toml theme={null}
# action
name    = "role_audit"
timeout = "30s"

[[triggers]]
type = "role-enabled"

[[triggers]]
type = "role-disabled"

[[steps]]
name            = "audit"
inline_contents = """
#!/usr/bin/env sh
echo "Role change detected — running audit"
"""
```

The following triggers require a `component_name` field to be set, as they are tied to a specific component:

* `pre-deploy-component`
* `post-deploy-component`
* `post-teardown-component`
* `pre-teardown-component`

Actions can be triggered manually, on a cron, or by install events. You can define multiple triggers for an action.

The example action defines two triggers. It will run every five minutes, and can also be triggered manually at any time.

```toml actions/<action-name>.toml theme={null}
# action
[[triggers]]
type          = "cron"
cron_schedule = "*/5 * * * *"

[[triggers]]
type = "manual"
```

### Steps

Each step in an action requires a command to be run. You can optionally load a script from a repo and provide env vars to configure the environment the command will run in.

The example action is pretty simple, so it has only one step. It loads a curl script from our [open-source repo of commonly-used scripts](https://github.com/nuonco/actions), and sets a few env vars to configure it.

```toml actions/<action-name>.toml theme={null}
# action
[[steps]]
name    = "healthcheck"
command = "./healthcheck"

[steps.public_repo]
repo      = "nuonco/actions"
branch    = "main"
directory = "common"

[steps.env_vars]
ENDPOINT             = "https://your-app.{{.nuon.install.sandbox.outputs.public_domain.name}}"
METHOD               = "HEAD"
EXPECTED_STATUS_CODE = "200"
```

## Monitoring workflow runs

Action workflow runs can be monitored on the "Actions" tab in each install. You can see a list of all workflow runs, and inspect each run to see logs, what triggered the run, and whether it succeeded or not.