---
title: Working with Retry Count in Scripts
slug: working-with-retry-count-in-scripts
docTags: 
createdAt: 2026-05-04T01:47:27.585Z
---

Retryable workflow steps in Activate are created using Job.WorkFlow\.CallRetryable(...). When a step is configured this way, the platform automatically tracks retry state as part of the job execution. This includes how many times the step has been retried and whether the current attempt is the final one.

This retry metadata is exposed to scripts through the evaluator, allowing you to adjust behaviour dynamically based on the current retry context.

## Accessing Retry Information

```csharp
bool lastRetry = Job.Evaluator.GetBoolean(srv, "=//RetryLast", false);
int retryNumber = Job.Evaluator.GetInteger(null, "=//RetryTimes", -1);
```

RetryLast indicates whether the current execution is the final retry attempt.

RetryTimes returns the current retry count (starting from 0 or 1 depending on configuration and context).

Both methods include a fallback value to ensure the script continues safely if the retry context is not present.

## How It Works

When a retryable step is executed:

1. The workflow engine records retry configuration (such as max retries and delay).
2. Each time the step is retried, the retry counter is incremented.
3. The evaluator exposes this state via the =//RetryTimes and =//RetryLast expressions.
4. Scripts can read these values at runtime and alter behaviour accordingly.

This allows for more controlled and intelligent retry handling compared to static retry logic.

## Example Usage

```csharp
public JobWorkFlow.Result InternalWait(ServiceInstance srv)
{
    bool lastRetry = Job.Evaluator.GetBoolean(srv, "=//RetryLast", false);
    int retryNumber = Job.Evaluator.GetInteger(null, "=//RetryTimes", -1);

    // Apply different logic on a specific retry attempt
    if (retryNumber == 2)
    {
        Job.LogAudit("Retry logic", "Executing second retry behaviour.");
    }

    // Handle final retry differently
    if (lastRetry)
    {
        Job.LogError("Retry failed", "Final retry reached. Escalating.");
        return JobWorkFlow.Result.NextStep;
    }

    return JobWorkFlow.Result.Retry;
}
```

## Common Use Cases

- Escalating logging or alerting on the final retry
- Introducing alternative logic after a certain number of failures
- Adding delays or additional checks on later retries
- Preventing repeated execution of expensive operations

Using retry metadata in this way helps make workflows more resilient and reduces unnecessary failures or repeated actions.