From 69f3f41ba3df97425de68e7d0030572557c8bb3b Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Thu, 16 Jul 2026 17:08:29 +0200 Subject: [PATCH 01/10] feat(jobs): improve retries --- pages/serverless-jobs/concepts.mdx | 14 +++++++++++++- .../serverless-jobs/how-to/manage-job-retries.mdx | 2 +- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index 99010924b8..cf609bd27f 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -26,6 +26,10 @@ An environment variable is a variable whose value is set outside the program, ty In addition to CPU and RAM, Serverless Jobs also provide a storage volume for the duration of the task. This storage space allows to hold the data retrieved by the job, and disappears once the execution is complete. +## Exit code + +An exit code is an integer returned by a process when it finishes running. A value of `0` indicates success, while any non-zero value indicates an error. For Serverless Jobs, the exit code of a [job run](#job-run) determines its outcome: a non-zero exit code causes the job run to reach the `failed` status, which may trigger a [retry](#retries) if the configured retry count is greater than zero. See [Reason](#reason) (`exited_with_error`) for more information about non-zero exit codes. + ## GB-s Unit used to measure the resource consumption of a container. It reflects the amount of memory consumed over time. @@ -68,7 +72,15 @@ Refer to the [dedicated FAQ](/serverless-jobs/faq/#how-can-i-configure-access-to ## Retries -Retries refer to the automatic re-execution of a failed job run. You can configure Serverless Jobs to automatically retry a job run after up to five failed attempts. [Learn how to manage the retry attempts of a Serverless Job.](/serverless-jobs/how-to/manage-job-retries/) +Retries refer to the automatic re-execution of a failed job run. You can configure Serverless Jobs to automatically retry a job run after up to five failed attempts. + +A retry is triggered when all the following conditions are met: + +- The job run reaches the `failed` [Status](#status). +- The configured retry count is greater than zero. +- The job run exits with a non-zero exit code. + +[Learn how to manage the retry attempts of a Serverless Job.](/serverless-jobs/how-to/manage-job-retries/) ## Schedule (deprecated) diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 47de35af31..5b799c3f66 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,7 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option allows you to define how many times a Serverless Job automatically retries on failure. When the maximum number of failed retries is reached, the job is permanently marked as failed. +The retry option allows you to define how many times a Serverless Job automatically retries on failure. A retry is triggered when the job run reaches the `failed` [Status](/serverless-jobs/concepts/#status), the configured retry count is greater than zero, and the job run exits with a non-zero exit code. When the maximum number of failed retries is reached, the job is permanently marked as failed. From 452a2d0f4bacb1b23180e7a3d51026981b686fc8 Mon Sep 17 00:00:00 2001 From: Thomas TACQUET Date: Thu, 16 Jul 2026 17:22:32 +0200 Subject: [PATCH 02/10] Update pages/serverless-jobs/how-to/manage-job-retries.mdx Co-authored-by: Firdevs Arslan --- pages/serverless-jobs/how-to/manage-job-retries.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 5b799c3f66..30063f765f 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,7 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option allows you to define how many times a Serverless Job automatically retries on failure. A retry is triggered when the job run reaches the `failed` [Status](/serverless-jobs/concepts/#status), the configured retry count is greater than zero, and the job run exits with a non-zero exit code. When the maximum number of failed retries is reached, the job is permanently marked as failed. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry triggers when the job run reaches the `failed` [Status](/serverless-jobs/concepts/#status), the configured retry count is greater than zero, and the job run exits with a non-zero exit code. Once the job reaches the maximum number of failed retries, it is permanently marked as failed. From 7b14e82c021348cb8673ae21419c05b58ad3fb45 Mon Sep 17 00:00:00 2001 From: Thomas TACQUET Date: Fri, 17 Jul 2026 10:09:48 +0200 Subject: [PATCH 03/10] Update pages/serverless-jobs/concepts.mdx Co-authored-by: Loic-kd --- pages/serverless-jobs/concepts.mdx | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index cf609bd27f..9b5fc0a095 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -76,9 +76,8 @@ Retries refer to the automatic re-execution of a failed job run. You can configu A retry is triggered when all the following conditions are met: -- The job run reaches the `failed` [Status](#status). -- The configured retry count is greater than zero. -- The job run exits with a non-zero exit code. +- The job run does not succeed and exits with an exit code other than zero. +- The maximum number of retry attempts has not been reached. [Learn how to manage the retry attempts of a Serverless Job.](/serverless-jobs/how-to/manage-job-retries/) From ec747298287a69d8724d39b78da0db79a8a4fa73 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Fri, 17 Jul 2026 18:24:07 +0200 Subject: [PATCH 04/10] inprogress --- pages/serverless-jobs/how-to/manage-job-retries.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 30063f765f..7dc910c16a 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,7 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry triggers when the job run reaches the `failed` [Status](/serverless-jobs/concepts/#status), the configured retry count is greater than zero, and the job run exits with a non-zero exit code. Once the job reaches the maximum number of failed retries, it is permanently marked as failed. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry triggers when the Job Run returns an [Exit Code](/serverless-jobs/concepts/#exit-code) different than `0`. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. From c499ac5f786a583d6b385dfd545f1e41502512a9 Mon Sep 17 00:00:00 2001 From: Thomas TACQUET Date: Mon, 20 Jul 2026 16:46:24 +0200 Subject: [PATCH 05/10] Apply suggestion from @redanrd Co-authored-by: Reda <58738453+redanrd@users.noreply.github.com> --- pages/serverless-jobs/how-to/manage-job-retries.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 7dc910c16a..3d0ae17cb9 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,7 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry triggers when the Job Run returns an [Exit Code](/serverless-jobs/concepts/#exit-code) different than `0`. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered when the job run falls in a `Failed` state. Retry on `Interrupted` state is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. From 04089f275bf5a73d1f7d2b86985c339477c99048 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Mon, 20 Jul 2026 16:52:35 +0200 Subject: [PATCH 06/10] null exit code and retries improvements --- pages/serverless-jobs/concepts.mdx | 2 ++ pages/serverless-jobs/how-to/manage-job-retries.mdx | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index 9b5fc0a095..1443cef9be 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -30,6 +30,8 @@ In addition to CPU and RAM, Serverless Jobs also provide a storage volume for th An exit code is an integer returned by a process when it finishes running. A value of `0` indicates success, while any non-zero value indicates an error. For Serverless Jobs, the exit code of a [job run](#job-run) determines its outcome: a non-zero exit code causes the job run to reach the `failed` status, which may trigger a [retry](#retries) if the configured retry count is greater than zero. See [Reason](#reason) (`exited_with_error`) for more information about non-zero exit codes. +Note that the exit code can also be `null` when the job run fails before the container process runs or exits, for example when the reason is `image_not_found` or `technical_error`. In these cases the job run still reaches the `failed` status, but no exit code is returned by the runtime. + ## GB-s Unit used to measure the resource consumption of a container. It reflects the amount of memory consumed over time. diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 3d0ae17cb9..bd4c49077b 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,7 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered when the job run falls in a `Failed` state. Retry on `Interrupted` state is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `Failed` state, regardless of the exit code returned by the runtime. This includes runs that fail with a `null` exit code, such as those stopped by a platform mismatch or other infrastructure-side error. Retry on `Interrupted` state is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. From b08bdfae0f0cfca054f3707aaa0867423ab44172 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Mon, 20 Jul 2026 17:01:14 +0200 Subject: [PATCH 07/10] retries flow precision --- pages/serverless-jobs/concepts.mdx | 12 ++++++++---- pages/serverless-jobs/how-to/manage-job-retries.mdx | 7 ++++++- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index 1443cef9be..4dae4d92f5 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -28,9 +28,11 @@ In addition to CPU and RAM, Serverless Jobs also provide a storage volume for th ## Exit code -An exit code is an integer returned by a process when it finishes running. A value of `0` indicates success, while any non-zero value indicates an error. For Serverless Jobs, the exit code of a [job run](#job-run) determines its outcome: a non-zero exit code causes the job run to reach the `failed` status, which may trigger a [retry](#retries) if the configured retry count is greater than zero. See [Reason](#reason) (`exited_with_error`) for more information about non-zero exit codes. +An exit code is an integer returned by a process when it finishes running. A value of `0` indicates success, while any non-zero value indicates an error. For Serverless Jobs, the exit code of a [job run](#job-run) determines its outcome: -Note that the exit code can also be `null` when the job run fails before the container process runs or exits, for example when the reason is `image_not_found` or `technical_error`. In these cases the job run still reaches the `failed` status, but no exit code is returned by the runtime. +- **`0`** — the job run succeeds. +- **Non-zero** — the job run reaches the `failed` status, which may trigger a [retry](#retries) if the configured retry count is greater than zero. See [Reason](#reason) (`exited_with_error`) for more information about non-zero exit codes. +- **`null`** — the exit code is not set when the job run fails before the container process runs or exits. The job run still reaches the `failed` status, but no exit code is returned by the runtime. This typically happens for reasons such as `image_not_found` or `technical_error`. ## GB-s @@ -81,6 +83,8 @@ A retry is triggered when all the following conditions are met: - The job run does not succeed and exits with an exit code other than zero. - The maximum number of retry attempts has not been reached. +Note that `succeeded` and `failed` are **final** statuses. When a retry is configured and the job run encounters an error during execution, it does not transition through `failed` first. Instead, it goes directly from `running` to `retrying`, and only reaches `failed` once all retry attempts are exhausted (or `succeeded` if a retry succeeds). This means a job run that will be retried never passes through the `failed` status between attempts. + [Learn how to manage the retry attempts of a Serverless Job.](/serverless-jobs/how-to/manage-job-retries/) ## Schedule (deprecated) @@ -131,11 +135,11 @@ A Serverless Job run can have the following statuses: * **`failed`**: The job run finished with an error, see [Reason](#reason) for detailed information about the error. [Check our troubleshooting documentation](/serverless-jobs/troubleshooting/job-in-error-state/) to solve the issue. * **`interrupting`**: A request to stop the job (via user action or system preemption) is currently being processed. * **`interrupted`**: The job was stopped before it could finish naturally, see [Reason](#reason) for details about the interruption. -* **`retrying`**: The job run failed and is being automatically re-executed, based on the configured retry policy. See [Retries](#retries) for more information. +* **`retrying`**: The job run encountered an error during execution and is being automatically re-executed, based on the configured retry policy. Note that the job run transitions directly from `running` to `retrying` — it does not pass through `failed`, which is a final status only reached when all retry attempts are exhausted. See [Retries](#retries) for more information. Typical successful flow is: `initialized -> validated -> queued -> running -> succeeded`. -When retries are configured, a failed job run transitions to `retrying` before being re-executed: `initialized -> validated -> queued -> running -> failed -> retrying -> queued -> running -> succeeded`. +When retries are configured, a job run that errors during execution transitions directly from `running` to `retrying` (not through `failed`, which is a final status), then is re-executed: `initialized -> validated -> queued -> running -> retrying -> queued -> running -> succeeded`. Only when all retry attempts are exhausted does the job run reach the final `failed` status: `initialized -> validated -> queued -> running -> retrying -> queued -> running -> ... -> failed`. ### Reason diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index bd4c49077b..58eb807587 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,7 +9,12 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `Failed` state, regardless of the exit code returned by the runtime. This includes runs that fail with a `null` exit code, such as those stopped by a platform mismatch or other infrastructure-side error. Retry on `Interrupted` state is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `Failed` state, regardless of the exit code returned by the runtime. + +- **Retried** — job runs in a `Failed` state, including those that fail with a `null` exit code (e.g., platform mismatch or other infrastructure-side error). +- **Not retried** — job runs in an `Interrupted` state. Retry on `Interrupted` is not yet supported. + +Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. From a5b5539ee2aace056c0017acd0f8aeeda2660db2 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Tue, 21 Jul 2026 09:19:01 +0200 Subject: [PATCH 08/10] fix capitalization --- pages/serverless-jobs/how-to/manage-job-retries.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index 58eb807587..ee3d88e104 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,10 +9,10 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `Failed` state, regardless of the exit code returned by the runtime. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `failed` state, regardless of the exit code returned by the runtime. -- **Retried** — job runs in a `Failed` state, including those that fail with a `null` exit code (e.g., platform mismatch or other infrastructure-side error). -- **Not retried** — job runs in an `Interrupted` state. Retry on `Interrupted` is not yet supported. +- **Retried** — job runs in a `failed` state, including those that fail with a `null` exit code (e.g., platform mismatch or other infrastructure-side error). +- **Not retried** — job runs in an `interrupted` state. Retry on `interrupted` is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`. From 36a6e2ba2056c1c5c64d4c8c08c7f93896d265f4 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Tue, 21 Jul 2026 09:22:43 +0200 Subject: [PATCH 09/10] statuses categories --- pages/serverless-jobs/concepts.mdx | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index 4dae4d92f5..d660c4d2d7 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -126,16 +126,22 @@ Refer to the [official Kubernetes documentation](https://kubernetes.io/docs/task ## Status -A Serverless Job run can have the following statuses: +A Serverless Job run can have the following statuses, grouped into **transient statuses** (the job run is still progressing through its lifecycle) and **final statuses** (the job run has reached a terminal state and will not change anymore): + +### Transient statuses + * **`initialized`**: The job has been created in the system but has not yet entered the processing pipeline. * **`validated`**: The job configuration and resources have been verified and are ready for scheduling. * **`queued`**: The job is waiting for compute resources to become available. * **`running`**: The job run is currently being executed. +* **`interrupting`**: A request to stop the job (via user action or system preemption) is currently being processed. +* **`retrying`**: The job run encountered an error during execution and is being automatically re-executed, based on the configured retry policy. Note that the job run transitions directly from `running` to `retrying` — it does not pass through `failed`, which is a final status only reached when all retry attempts are exhausted. See [Retries](#retries) for more information. + +### Final statuses + * **`succeeded`**: The job has successfully completed. * **`failed`**: The job run finished with an error, see [Reason](#reason) for detailed information about the error. [Check our troubleshooting documentation](/serverless-jobs/troubleshooting/job-in-error-state/) to solve the issue. -* **`interrupting`**: A request to stop the job (via user action or system preemption) is currently being processed. * **`interrupted`**: The job was stopped before it could finish naturally, see [Reason](#reason) for details about the interruption. -* **`retrying`**: The job run encountered an error during execution and is being automatically re-executed, based on the configured retry policy. Note that the job run transitions directly from `running` to `retrying` — it does not pass through `failed`, which is a final status only reached when all retry attempts are exhausted. See [Retries](#retries) for more information. Typical successful flow is: `initialized -> validated -> queued -> running -> succeeded`. From ed2142c809310fc17d989ad3a337ce10e4b7fea9 Mon Sep 17 00:00:00 2001 From: Thomas Tacquet Date: Tue, 21 Jul 2026 09:36:51 +0200 Subject: [PATCH 10/10] use status instead of state --- pages/serverless-jobs/concepts.mdx | 2 +- pages/serverless-jobs/how-to/manage-job-retries.mdx | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/pages/serverless-jobs/concepts.mdx b/pages/serverless-jobs/concepts.mdx index d660c4d2d7..9e157e0b60 100644 --- a/pages/serverless-jobs/concepts.mdx +++ b/pages/serverless-jobs/concepts.mdx @@ -126,7 +126,7 @@ Refer to the [official Kubernetes documentation](https://kubernetes.io/docs/task ## Status -A Serverless Job run can have the following statuses, grouped into **transient statuses** (the job run is still progressing through its lifecycle) and **final statuses** (the job run has reached a terminal state and will not change anymore): +A Serverless Job run can have the following statuses, grouped into **transient statuses** (the job run is still progressing through its lifecycle) and **final statuses** (the job run has reached a terminal status and will not change anymore): ### Transient statuses diff --git a/pages/serverless-jobs/how-to/manage-job-retries.mdx b/pages/serverless-jobs/how-to/manage-job-retries.mdx index ee3d88e104..e814585f16 100644 --- a/pages/serverless-jobs/how-to/manage-job-retries.mdx +++ b/pages/serverless-jobs/how-to/manage-job-retries.mdx @@ -9,10 +9,10 @@ dates: import Requirements from '@macros/iam/requirements.mdx' -The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `failed` state, regardless of the exit code returned by the runtime. +The retry option lets you define how many times a Serverless Job automatically retries on failure. A retry is triggered whenever a job run ends in a `failed` status, regardless of the exit code returned by the runtime. -- **Retried** — job runs in a `failed` state, including those that fail with a `null` exit code (e.g., platform mismatch or other infrastructure-side error). -- **Not retried** — job runs in an `interrupted` state. Retry on `interrupted` is not yet supported. +- **Retried** — job runs in a `failed` status, including those that fail with a `null` exit code (e.g., platform mismatch or other infrastructure-side error). +- **Not retried** — job runs in an `interrupted` status. Retry on `interrupted` is not yet supported. Once the job reaches the maximum number of failed retries, it is permanently marked as `failed`.