From 32f8a6e22d3201a0f932f49c373761703403ed51 Mon Sep 17 00:00:00 2001 From: "qovery-docs-agent[bot]" <335531142+qovery-docs-agent[bot]@users.noreply.github.com> Date: Tue, 29 Sep 2026 13:34:16 +0000 Subject: [PATCH 1/3] docs(console): document build settings page, JSON log formatting, agent task resource minimums - Build settings: new dedicated page in service settings, build.* keys no longer listed in Advanced settings (service-advanced-settings, application, troubleshoot) - Service logs: JSON object messages are displayed formatted (deployment/logs) - Agent tasks: CPU and memory are required with minimums of 1000 mCPU and 2048 MiB (agent-tasks/overview) Co-Authored-By: Claude Code --- docs/configuration/agent-tasks/overview.mdx | 2 +- docs/configuration/application.mdx | 12 +++++++++++- docs/configuration/deployment/logs.mdx | 2 ++ .../configuration/service-advanced-settings.mdx | 17 +++++++++++++++++ docs/getting-started/troubleshoot/overview.mdx | 4 ++-- 5 files changed, 33 insertions(+), 4 deletions(-) diff --git a/docs/configuration/agent-tasks/overview.mdx b/docs/configuration/agent-tasks/overview.mdx index 10fb618a..c6b13d79 100644 --- a/docs/configuration/agent-tasks/overview.mdx +++ b/docs/configuration/agent-tasks/overview.mdx @@ -120,7 +120,7 @@ Some agents use a different, more direct pattern instead: storing a chat webhook A description of what the agent does. - CPU (mCPU), memory (MB), and storage (GB) allocated to the agent, same as any other Qovery service. + CPU (mCPU), memory (MiB), and storage (GB) allocated to the agent, same as any other Qovery service. CPU and memory are required, with a minimum of 1000 mCPU and 2048 MiB. The ready-made templates start at these minimums. A domain allowlist controls which external hosts the agent task can reach: comma-separated hostnames, or `*` for all domains. diff --git a/docs/configuration/application.mdx b/docs/configuration/application.mdx index fc797b62..2e3a7325 100644 --- a/docs/configuration/application.mdx +++ b/docs/configuration/application.mdx @@ -854,11 +854,21 @@ Duplicate an application configuration to the same or different environment. Clo prevent conflicts. +### Build Settings + +Configure how your application is built from **Settings** > **Build settings**: + +- Build timeout +- CPU, RAM, and ephemeral storage available to the build +- BuildKit cache +- Git submodules + +See [Build Settings](/configuration/service-advanced-settings#build-settings) for details. + ### Advanced Settings Configure advanced options including: -- Build timeout and resources - Deployment strategy - Network settings - Node affinity diff --git a/docs/configuration/deployment/logs.mdx b/docs/configuration/deployment/logs.mdx index af2704cc..72e64337 100644 --- a/docs/configuration/deployment/logs.mdx +++ b/docs/configuration/deployment/logs.mdx @@ -113,6 +113,8 @@ Each log entry displays: - **Container**: Container name - **Message**: The actual log content +When a log message is a valid JSON object, the Console displays it formatted over several lines with indentation, and highlights the keys with an accent color. Messages that are not JSON objects, such as plain text or JSON arrays, are displayed as they are. + ### Filtering Logs ![Filtered Logs](/images/deployment/live_logs_filtered.png) diff --git a/docs/configuration/service-advanced-settings.mdx b/docs/configuration/service-advanced-settings.mdx index 28d4366a..dcce3809 100644 --- a/docs/configuration/service-advanced-settings.mdx +++ b/docs/configuration/service-advanced-settings.mdx @@ -43,6 +43,23 @@ Use the **Show only overridden** toggle to view only settings that differ from d ## Build Settings +For Applications, Cronjobs, Lifecycle jobs, and Terraform services, the `build.*` settings are not listed in **Advanced settings** in the Qovery Console. Edit them from the dedicated **Build settings** page, available in the service **Settings** just before **Advanced settings**. + +| Field in the Console | Setting | +|----------------------|---------| +| Timeout (seconds) | [`build.timeout_max_sec`](#build-timeout-max-sec) | +| CPU (millicores) | [`build.cpu_max_in_milli`](#build-cpu-max-in-milli) | +| RAM (GiB) | [`build.ram_max_in_gib`](#build-ram-max-in-gib) | +| Ephemeral storage (GiB) | [`build.ephemeral_storage_in_gib`](#build-ephemeral-storage-in-gib) | +| Disable BuildKit cache | [`build.disable_buildkit_cache`](#build-disable-buildkit-cache) | +| Skip Git submodules | [`build.skip_git_submodules`](#build-skip-git-submodules) | + +The placeholder of each numeric field shows the default value. The **Disable BuildKit cache** toggle is not displayed for Terraform services. + + +If build settings customization is not available for your organization, the fields are read-only and the page displays a message with a **Contact support** button. + + ### build.timeout_max_sec diff --git a/docs/getting-started/troubleshoot/overview.mdx b/docs/getting-started/troubleshoot/overview.mdx index 59ac8ec0..1e5718ac 100644 --- a/docs/getting-started/troubleshoot/overview.mdx +++ b/docs/getting-started/troubleshoot/overview.mdx @@ -202,8 +202,8 @@ Find solutions for the most common deployment errors and issues you may encounte - 1. Go to your service **Settings** → **Advanced Settings** - 2. Find the **build.timeout_max_sec** parameter + 1. Go to your service **Settings** → **Build settings** + 2. Find the **Timeout (seconds)** field (the `build.timeout_max_sec` setting) 3. Increase the value (e.g., `3600` for 1 hour) 4. Save and redeploy From b84f94875891fd01d1d6618afd5736ddb8f1be66 Mon Sep 17 00:00:00 2001 From: "qovery-docs-agent[bot]" <335531142+qovery-docs-agent[bot]@users.noreply.github.com> Date: Tue, 29 Sep 2026 14:04:02 +0000 Subject: [PATCH 2/3] docs(console): document agent task model/token, save behavior, optimizer template and environment sorting - Agent tasks: AWS region for Bedrock tokens, Edit token button, model-load error hints (Console #3005) - Agent tasks: Connections, Automations, Outputs and Dockerfile fragment are saved from their modal or side panel (Console #3001) - Build & Deployment Optimizer: read-only, skill-based template that opens PRs and lists Console/API-only changes as recommendations (Console #3024) - Environments: sortable environment table and services list columns (Console #3020) Co-Authored-By: Claude Code --- .../agent-tasks/build-deployment-optimizer.mdx | 18 ++++++++++-------- docs/configuration/agent-tasks/overview.mdx | 6 ++++-- docs/configuration/environment.mdx | 10 ++++++++++ docs/getting-started/agent-tasks.mdx | 2 +- 4 files changed, 25 insertions(+), 11 deletions(-) diff --git a/docs/configuration/agent-tasks/build-deployment-optimizer.mdx b/docs/configuration/agent-tasks/build-deployment-optimizer.mdx index c07d694b..51ab2159 100644 --- a/docs/configuration/agent-tasks/build-deployment-optimizer.mdx +++ b/docs/configuration/agent-tasks/build-deployment-optimizer.mdx @@ -9,17 +9,19 @@ import AgentTasksEarlyPreviewWarning from '/snippets/agent-tasks-early-preview-w ## Overview -Identifies build and deployment optimization levers and their expected gain, then opens a PR with the proposed change and/or updates the build configuration in Qovery directly. It never merges a fix on its own. +Analyzes build and deployment speed for a service or environment with the [`qovery-speedup`](https://github.com/Qovery/qovery-skills/tree/main/qovery-speedup) skill, then opens a PR for each proposed change. The template's instructions tell the agent not to apply any change directly, and never to merge a PR on its own. ## How It Works To find concrete ways to make builds and deployments faster and cheaper, the agent: -1. Inspects the service's build setup: Dockerfile, dependency installation, layer caching, image size, and the build/deploy configuration in Qovery. -2. Identifies optimization levers, for example better layer ordering and caching, multi-stage builds, smaller base images, pruning unused dependencies, or parallelisable steps. -3. For each lever, estimates the expected gain (build time, image size, or cost) and the risk. -4. Opens a PR with the proposed changes to the build configuration, and/or updates the build configuration in Qovery directly. -5. Summarises what it changed, the expected gain, and anything that needs a human decision. It never merges, the human always stays the gate. +1. Loads the `qovery-speedup` skill and follows it to analyze build and deployment speed for the current service or environment. +2. Inspects the setup, identifies the bottlenecks, and diagnoses their root causes, including whether a slow build is an avoidable image-mirroring miss. +3. For every proposed change to a file in a repository (Dockerfile, build configuration, Infrastructure as Code such as Terraform), opens a PR on the relevant repository with a before/after and the expected gain. It never merges it. +4. For a change that can only be made from the Qovery Console or API, it does not call the mutating endpoint. It lists the change as a recommendation in its summary, with the exact change needed and the expected gain. +5. Finishes with a summary of what it found, what is proposed in which PR, and what needs a human decision. The human always stays the gate. + +The template's domain allowlist is pre-filled with `github.com`, `api.github.com`, `raw.githubusercontent.com`, `gitlab.com`, `bitbucket.org`, and `api.bitbucket.org`. ## Setting It Up @@ -33,7 +35,7 @@ To find concrete ways to make builds and deployments faster and cheaper, the age Since you added the service as Context, Qovery's own MCP server is created and selected automatically: organization-scoped, read-only, backed by a Viewer API token. That's enough for the agent to **propose** changes (open a PR). - To let it **apply** changes to Qovery directly instead, add the MCP server manually with an API Policy Token that has write permissions on that service's build/deploy configuration. See [Add MCP Servers](/configuration/agent-tasks/overview#creating-an-agent). + The template's instructions tell the agent never to apply changes to Qovery directly. If you edit the instructions to let it **apply** changes, add the MCP server manually with an API Policy Token that has write permissions on that service's build/deploy configuration. See [Add MCP Servers](/configuration/agent-tasks/overview#creating-an-agent). Add a schedule trigger, for example weekly, to periodically review build performance, or a webhook trigger. See [Triggers](/configuration/agent-tasks/overview#triggers) for how they work in general. @@ -42,7 +44,7 @@ To find concrete ways to make builds and deployments faster and cheaper, the age This agent is typically run on a schedule rather than triggered concurrently, so **In Place** (the default) works well. Use **Clone Environment** instead if you expect overlapping runs. See [Execution Mode](/configuration/agent-tasks/overview#execution-mode). - Click **Trigger** on the agent task's overview page to run it on demand. Check the run under its **Deployments** tab, and review the PR it opened (or the build configuration it updated, if you granted write access). + Click **Trigger** on the agent task's overview page to run it on demand. Check the run under its **Deployments** tab, and review the PRs it opened and the recommendations in its summary. diff --git a/docs/configuration/agent-tasks/overview.mdx b/docs/configuration/agent-tasks/overview.mdx index c6b13d79..a3da8695 100644 --- a/docs/configuration/agent-tasks/overview.mdx +++ b/docs/configuration/agent-tasks/overview.mdx @@ -25,9 +25,9 @@ Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on yo Connect a Qovery service, a Git repository, or both, for the agent to load as context. A Qovery service's linked Git repository is included automatically, no need to add it separately, connect a repository on its own only when it isn't tied to a Qovery service. - Pick **Claude** (Anthropic) or **AWS Bedrock**, then select an existing token or create a new one on the fly. A token created here is saved and can be reused by any other agent task in the organization, no need to re-enter credentials each time. Tokens can also be managed centrally from **Organization Settings > Agent > Token**. + Pick **Claude** (Anthropic) or **AWS Bedrock**, then select an existing token or create a new one on the fly. A token created here is saved and can be reused by any other agent task in the organization, no need to re-enter credentials each time. Tokens can also be managed centrally from **Organization Settings > Agent > Token**. When you create an AWS Bedrock token, also select its **AWS region** (`eu-west-1` by default). - Once a token is selected, pick the **Model** the agent runs on from the list of models available to that token. The first available model is selected by default. For AWS Bedrock, the models offered depend on the token's AWS region. You can change the model later from the agent task's **Settings > AI configuration**. + Once a token is selected, pick the **Model** the agent runs on from the list of models available to that token. The first available model is selected by default. For AWS Bedrock, the models offered depend on the token's AWS region. If the models can't be loaded, check the token's API key (Claude) or its AWS credentials and region (AWS Bedrock). Use **Edit token** next to the token selector to update the selected token. You can change the model later from the agent task's **Settings > AI configuration**. If you added a Qovery service as Context in the previous step, Qovery's own MCP server is created and selected automatically: organization-scoped, read-only, backed by a Viewer API token. No URL, header, or token to configure. This is also preconfigured for the Incident Analyzer (incident.io and Honeybadger) and Build & deployment optimizer templates. @@ -133,6 +133,8 @@ Some agents use a different, more direct pattern instead: storing a chat webhook +On an existing agent task, the **Connections**, **Automations**, and **Outputs** settings, and the Dockerfile fragment under **Advanced settings**, are edited in a modal or side panel and saved from there with **Save**. These pages have no page-level save button. If saving fails, the modal or side panel stays open and shows an error. + ## After You Create It Agent Tasks appear in your environment overview under **Agent Tasks**, jobs delegated to AI agents, run once or on a schedule. Each one lists its status, last operation, underlying model, and a dedicated webhook URL you can call to trigger it from outside Qovery. That same webhook URL is also shown on the agent task's own overview page. diff --git a/docs/configuration/environment.mdx b/docs/configuration/environment.mdx index 19dd46a9..5b733cc8 100644 --- a/docs/configuration/environment.mdx +++ b/docs/configuration/environment.mdx @@ -72,6 +72,16 @@ After creation, you can add services including: ![Create Service](/images/configuration/environment/create_service.png) +## Environment List + +In the Qovery Console, the environments of a project are grouped in one table per mode: **Production**, **Staging**, **Development**, and **Ephemeral** (Preview environments). Each table lists the environment, its last operation, its cluster, and its last update. + +Click the **Environment**, **Last operation**, **Cluster**, or **Last update** column header to sort a table. Each click on the same header switches between ascending and descending order, and a third click goes back to the default order. The sort arrow only appears once you select a sort, and each table is sorted independently. + +By default, the Ephemeral table shows the most recent operation first, and the other tables are sorted alphabetically by environment name. + +The services list of an environment supports the same click behavior on its **Service** and **Last operation** columns. + ## Environment Settings Access environment settings to configure various aspects of your environment: diff --git a/docs/getting-started/agent-tasks.mdx b/docs/getting-started/agent-tasks.mdx index 797b1a54..7133ec98 100644 --- a/docs/getting-started/agent-tasks.mdx +++ b/docs/getting-started/agent-tasks.mdx @@ -47,7 +47,7 @@ Today there are a few ready-made agent configurations, or you can start from scr Same behavior, for teams using Honeybadger instead of incident.io. - Identifies build and deployment optimization levers and expected gain, opens a PR with the proposed change and/or modifies the build configuration in Qovery. + Analyzes build and deployment speed, opens a PR with each proposed change, and lists any change only possible from the Qovery Console as a recommendation. Picks up a Jira issue and proposes the corresponding code change as a pull request. From 24982a95c2c9a9858256929f3e482f570fd3c7af Mon Sep 17 00:00:00 2001 From: "qovery-docs-agent[bot]" <335531142+qovery-docs-agent[bot]@users.noreply.github.com> Date: Thu, 1 Oct 2026 12:52:42 +0000 Subject: [PATCH 3/3] docs(console): document Automations tab, template catalog and agent task runs Agent tasks are now created from the environment Automations tab (Create agent task > Create from template / Create from scratch) instead of the Agent use cases section of New service. Add the expanded template catalog, the Request agent template action, the agent task Runs tab with run details, and the Last run section. Co-Authored-By: Claude Code --- .../build-deployment-optimizer.mdx | 2 +- .../incident-analyser-honeybadger.mdx | 2 +- .../agent-tasks/incident-analyser.mdx | 2 +- .../agent-tasks/jira-coding-agent.mdx | 2 +- .../agent-tasks/linear-coding-agent.mdx | 2 +- docs/configuration/agent-tasks/overview.mdx | 43 +++++++++++++++---- docs/getting-started/agent-tasks.mdx | 6 +-- 7 files changed, 42 insertions(+), 17 deletions(-) diff --git a/docs/configuration/agent-tasks/build-deployment-optimizer.mdx b/docs/configuration/agent-tasks/build-deployment-optimizer.mdx index 51ab2159..558e474f 100644 --- a/docs/configuration/agent-tasks/build-deployment-optimizer.mdx +++ b/docs/configuration/agent-tasks/build-deployment-optimizer.mdx @@ -27,7 +27,7 @@ The template's domain allowlist is pre-filled with `github.com`, `api.github.com - From the **Agent use cases** section when creating a new service, pick **Build & deployment optimizer** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or start from scratch and paste in the instructions above. + From your environment's **Automations** tab, click **Create agent task > Create from template** and pick **Build & deployment optimizer** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or choose **Create from scratch** and paste in the instructions above. Add the Qovery service to optimize as its Context, its linked Git repository is included automatically so the agent can inspect the Dockerfile and build setup. Add a repository on its own only if it isn't tied to a Qovery service. diff --git a/docs/configuration/agent-tasks/incident-analyser-honeybadger.mdx b/docs/configuration/agent-tasks/incident-analyser-honeybadger.mdx index 16c02107..91c976eb 100644 --- a/docs/configuration/agent-tasks/incident-analyser-honeybadger.mdx +++ b/docs/configuration/agent-tasks/incident-analyser-honeybadger.mdx @@ -26,7 +26,7 @@ When an incident fires, the agent: - From the **Agent use cases** section when creating a new service, pick **Incident Analyzer with Honeybadger** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or start from scratch and paste in the instructions above. + From your environment's **Automations** tab, click **Create agent task > Create from template** and pick **Incident Analyzer with Honeybadger** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or choose **Create from scratch** and paste in the instructions above. Add the Qovery service(s) this agent should investigate as its Context, their linked Git repository is included automatically so the agent can read recent commits and merged PRs around the incident. Add a repository on its own only if it isn't tied to a Qovery service. diff --git a/docs/configuration/agent-tasks/incident-analyser.mdx b/docs/configuration/agent-tasks/incident-analyser.mdx index 6dd8284f..68079ee7 100644 --- a/docs/configuration/agent-tasks/incident-analyser.mdx +++ b/docs/configuration/agent-tasks/incident-analyser.mdx @@ -26,7 +26,7 @@ When an incident fires, the agent: - From the **Agent use cases** section when creating a new service, pick **Incident Analyzer with incident.io** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or start from scratch and paste in the instructions above. + From your environment's **Automations** tab, click **Create agent task > Create from template** and pick **Incident Analyzer with incident.io** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)), or choose **Create from scratch** and paste in the instructions above. Add the Qovery service(s) this agent should investigate as its Context, their linked Git repository is included automatically so the agent can read recent commits and merged PRs around the incident. Add a repository on its own only if it isn't tied to a Qovery service. diff --git a/docs/configuration/agent-tasks/jira-coding-agent.mdx b/docs/configuration/agent-tasks/jira-coding-agent.mdx index eb3b2e42..cff453ff 100644 --- a/docs/configuration/agent-tasks/jira-coding-agent.mdx +++ b/docs/configuration/agent-tasks/jira-coding-agent.mdx @@ -18,7 +18,7 @@ Picks up a Jira issue and proposes the corresponding code change as a pull reque - From the **Agent use cases** section when creating a new service, pick **Jira Coding Agent** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)). + From your environment's **Automations** tab, click **Create agent task > Create from template** and pick **Jira Coding Agent** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)). The template ships with three environment variables for connecting to Jira: a base URL (for example `https://company.atlassian.net`), an email, and an API token. Add `company.atlassian.net` to the domain allowlist so the agent can reach the Jira API. If you don't need Jira access for your workflow, remove these and adapt the instructions accordingly. diff --git a/docs/configuration/agent-tasks/linear-coding-agent.mdx b/docs/configuration/agent-tasks/linear-coding-agent.mdx index 18f4918d..6025f317 100644 --- a/docs/configuration/agent-tasks/linear-coding-agent.mdx +++ b/docs/configuration/agent-tasks/linear-coding-agent.mdx @@ -18,7 +18,7 @@ Picks up a Linear issue and proposes the corresponding code change as a pull req - From the **Agent use cases** section when creating a new service, pick **Linear Coding Agent** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)). + From your environment's **Automations** tab, click **Create agent task > Create from template** and pick **Linear Coding Agent** (see [Creating an Agent](/configuration/agent-tasks/overview#creating-an-agent)). The template ships with one environment variable for connecting to Linear: an API key. If you don't need Linear access for your workflow, remove it and adapt the instructions accordingly. diff --git a/docs/configuration/agent-tasks/overview.mdx b/docs/configuration/agent-tasks/overview.mdx index a3da8695..d6f5a1a5 100644 --- a/docs/configuration/agent-tasks/overview.mdx +++ b/docs/configuration/agent-tasks/overview.mdx @@ -14,12 +14,10 @@ Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on yo ## Creating an Agent - - In your environment, click **New Service > Create new service**. Under **Agent use cases**, pick a ready-made template (see [Tutorials](#tutorials) below) or **Start from scratch**. + + In your environment, open the **Automations** tab and click **Create agent task**. Choose **Create from template** to pick a ready-made template (see [Ready-Made Templates](#ready-made-templates) below), or **Create from scratch** to configure every part yourself. - - Create new service screen showing the Agent use cases section - + While the environment has no agent task yet, the **Automations** tab shows the template catalog directly. Selecting a template opens the creation form pre-filled with that template. Connect a Qovery service, a Git repository, or both, for the agent to load as context. A Qovery service's linked Git repository is included automatically, no need to add it separately, connect a repository on its own only when it isn't tied to a Qovery service. @@ -58,6 +56,18 @@ Agent Tasks are one-time or scheduled jobs delegated to AI agents, running on yo New agent task form with Context, Provider, MCP, Automations, and Instructions on the left, and Resources, Governance, Environment variables, and Advanced settings on the right +## Ready-Made Templates + +The template catalog groups the available templates by category: + +- **Optimization**: [Build & deployment optimizer](/configuration/agent-tasks/build-deployment-optimizer) +- **Incident Analyzer**: [Incident Analyzer with incident.io](/configuration/agent-tasks/incident-analyser), [Incident Analyzer with Honeybadger](/configuration/agent-tasks/incident-analyser-honeybadger), Sentry Incident Analyzer, and Incident Analyzer +- **Coding Agent**: [Jira Coding Agent](/configuration/agent-tasks/jira-coding-agent), [Linear Coding Agent](/configuration/agent-tasks/linear-coding-agent), Slack Coding Agent, and Coding Agent + +Sentry Incident Analyzer and Slack Coding Agent ship with a secret environment variable to fill in (`SENTRY_AUTH_TOKEN` and `SLACK_BOT_TOKEN` respectively), and a domain allowlist pre-filled with the hosts they need (`sentry.io` and `*.sentry.io`, or `slack.com`, plus GitHub, GitLab, and Bitbucket). Incident Analyzer and Coding Agent are not tied to a specific provider: they work on the payload sent to their webhook. + +If the template you need isn't listed, click **Request agent template** in the **Automations** tab, describe the template you'd like Qovery to add next, and click **Send request**. + ## Execution Mode Choose where the agent runs when it's triggered: @@ -69,7 +79,7 @@ Choose where the agent runs when it's triggered: In **In Place** mode, a new trigger replaces the currently running execution, there's no run history if the agent is triggered multiple times. Use **Clone Environment** for agents that can be triggered frequently or concurrently, and **In Place** for agents on a predictable schedule where overlap isn't a concern. -Each ready-made template has a sensible default: Incident Analyzer (both the incident.io and Honeybadger variants), Jira Coding Agent, and Linear Coding Agent default to Clone Environment, since an incident or a labeled ticket can trigger them frequently or concurrently. Build & deployment optimizer, typically run on a schedule, defaults to In Place. +Each ready-made template has a sensible default: the Incident Analyzer and Coding Agent templates default to Clone Environment, since an incident, a ticket, or a request can trigger them frequently or concurrently. Build & deployment optimizer, typically run on a schedule, defaults to In Place. ### Limits @@ -80,7 +90,7 @@ Each ready-made template has a sensible default: Incident Analyzer (both the inc ## Triggers and Outputs -Add a trigger to run the agent automatically, and optionally an output to send its result somewhere when it's done. You can also trigger any agent task on demand: click the **Trigger** (play) button on its overview page, or from the environment's services list. +Add a trigger to run the agent automatically, and optionally an output to send its result somewhere when it's done. You can also trigger any agent task on demand: click the **Trigger** (play) button on its overview page, or from the **Agent tasks** list in the environment's **Automations** tab. Agent task overview page with the Trigger play button highlighted in the top right @@ -89,7 +99,7 @@ Add a trigger to run the agent automatically, and optionally an output to send i ### Triggers - **On a schedule**: a cron expression and timezone, for example `0 8 * * 1-5` for 8:00 AM, Monday through Friday. -- **From a webhook**: Qovery generates a unique URL for the agent task, visible later in the environment's **Agent Tasks** list (for example `https://webhook.qovery.com/api/v1/hook/...`). Anything that can send a POST request to that URL starts the agent. +- **From a webhook**: Qovery generates a unique URL for the agent task, visible later by hovering **Webhook** in the **Trigger** column of the **Agent tasks** list in the environment's **Automations** tab (for example `https://webhook.qovery.com/api/v1/hook/...`). Anything that can send a POST request to that URL starts the agent. ### Outputs @@ -137,7 +147,22 @@ On an existing agent task, the **Connections**, **Automations**, and **Outputs** ## After You Create It -Agent Tasks appear in your environment overview under **Agent Tasks**, jobs delegated to AI agents, run once or on a schedule. Each one lists its status, last operation, underlying model, and a dedicated webhook URL you can call to trigger it from outside Qovery. That same webhook URL is also shown on the agent task's own overview page. +Agent tasks appear in the **Agent tasks** list of your environment's **Automations** tab, one-time tasks delegated to AI agents. Each one lists its name, whether it is enabled, its state, its last operation, and its trigger: **Schedule** with the date of the next run (or **Paused**), or **Webhook**, whose dedicated URL you can call to trigger the agent from outside Qovery. That same webhook URL is also shown on the agent task's own overview page. + +## Run History + +The **Runs** tab of an agent task lists its runs, with these columns: + +- **Date**: when the run started and, once finished, when it ended (UTC), with the run ID. Hover the date to see the exact start and end times, or click the copy icon next to the run ID to copy it. +- **Status**: `Queued`, `Running`, `Completed`, `Failed`, or `Cancelled`. +- **Trigger**: `Manual`, `Schedule`, or `Webhook`. +- **Payload**: the payload recorded for the run, or `—` when there is none. +- **Duration**: how long the run took. +- **Prompt**: the prompt the run used. + +Click a run to open its **Run details** side panel, which shows the run ID, trigger, status, start and end times (UTC), duration, full payload, and full prompt. Until the agent task has run, the tab shows **No runs yet**: use the **Trigger** (play) button in the header to start one. + +The agent task's overview page also has a **Last run** section showing the trigger, how long ago the latest run happened, and its status. Click it to open that run's details, or click **See all runs** to go to the **Runs** tab. The **Deployments** tab of an agent task lists its deployments, like any other service. ## Tutorials diff --git a/docs/getting-started/agent-tasks.mdx b/docs/getting-started/agent-tasks.mdx index 7133ec98..9435ce47 100644 --- a/docs/getting-started/agent-tasks.mdx +++ b/docs/getting-started/agent-tasks.mdx @@ -22,7 +22,7 @@ Agent Tasks let you delegate a job, investigating an incident, optimizing a buil Scoped access via Policy API tokens, network boundaries from a domain allowlist controlling exactly what it can reach, resource limits, and execution timeouts, the same governance model as any other Qovery service. - Every run shows up under the agent task's Deployments tab, with logs, like any other deployment. + Every run is listed under the agent task's Runs tab with its trigger, status, payload, and prompt, and shows up under its Deployments tab, with logs, like any other deployment. Clone Environment mode gives a run its own throwaway copy of the environment, so an agent investigating an incident or proposing a code change can't interfere with what's actually running in production. @@ -37,7 +37,7 @@ Agent Tasks let you delegate a job, investigating an incident, optimizing a buil ## Use Cases -Today there are a few ready-made agent configurations, or you can start from scratch and configure every part yourself. Don't hesitate to reach out to us directly in the product if you have a specific need so we can add it. +Today there are a few ready-made agent configurations, listed in the [template catalog](/configuration/agent-tasks/overview#ready-made-templates) of your environment's **Automations** tab, or you can create an agent task from scratch and configure every part yourself. Don't hesitate to reach out to us directly in the product if you have a specific need so we can add it. @@ -55,7 +55,7 @@ Today there are a few ready-made agent configurations, or you can start from scr Picks up a Linear issue and proposes the corresponding code change as a pull request. - + Configure every part of the agent yourself. Also the full configuration reference: creating an agent, execution mode, triggers and outputs, resources, governance, and environment variables.