> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/automate-protect-and-extend/automation/task-engine.md).

# Task Engine

Overview of the VergeOS Task Engine for automating operations with event-based and schedule-based triggers, including modular architecture for tasks, schedules, events, and webhooks.

The **Task Engine** enables automated operations in VergeOS, triggered either by specific events or scheduled times. Defined tasks can run once or recur based on your configuration.

## Event-Based Task Examples

Tasks are triggered automatically when a defined event occurs:

* Send an email notification when a system update completes
* Power on a specific virtual machine when a designated user logs into VergeOS
* Use a webhook to notify an external alerting system when a sync error is detected

## Schedule-Based Task Examples

Tasks run at predefined times or intervals:

* Check for and download system updates every Saturday at 5:00 PM
* Disable a user account (e.g., for a temporary employee) 30 days after creation
* Power off a tenant on a specific date

## Task Engine Components

| Component     | Description                                                                 |
| ------------- | --------------------------------------------------------------------------- |
| **Tasks**     | Define the action to perform (e.g., power off a VM, send a notification)    |
| **Schedules** | Specify when and how often a task should run (e.g., daily, weekly)          |
| **Events**    | Define conditions that trigger a task (e.g., user login, sync failure)      |
| **Webhooks**  | Special tasks that push data to external systems in real time               |
| **Task Logs** | Record task creation and execution history for auditing and troubleshooting |

## Modular Automation Architecture

The VergeOS Task Engine supports flexible orchestration of tasks, events, schedules, and webhooks. This modular design enables scalable, reusable automation tailored to your environment:

* **Assign multiple tasks or events to a single webhook** — for example, you can configure a webhook to notify an external system, and have it triggered by several different events such as sync failures, login attempts, or system alerts. This reduces duplication and centralizes external integrations.
* **Trigger a single task from multiple distinct events** — such as powering on a virtual machine when either a specific user logs in or when a scheduled maintenance window begins. This allows you to consolidate logic and reuse task definitions across scenarios.
* **Create a schedule once and apply it to multiple tasks** — for example, define a weekly maintenance window and link it to several update, alerting, or shutdown tasks. This promotes consistency and simplifies configuration management.

This modular design enables scalable, reusable automation tailored to your environment.

***

## Related Guides

* [Creating Automated Tasks](/automate-protect-and-extend/automation/create-tasks.md)
* [Using Webhooks](/automate-protect-and-extend/automation/webhooks.md)
* [Defining Schedules](/automate-protect-and-extend/automation/schedules.md)

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.verge.io/automate-protect-and-extend/automation/task-engine.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.