Retry

There are many P-KPIs that the platform could report to the dashboard for a given station. Depending on the type of station, a specific subset of P-KPIs might be more appropriate. If your station is reporting test data by using SDK functions that track the unit in and out of the station with a corresponding result, it might be helpful to understand how retry rates are counted and calculated.

Retry Rate

Retry Rate measures how often units are re-processed at a given station, station group, or line. This metric indicates the proportion of unique units that required one or more additional runs beyond their initial attempt — a strong signal of test and process stability.

Retry Rate calculations are based on how many times each unique unit is tracked out of a station. If a unit is processed multiple times, all occurrences after the first are considered retries.

$$\text{Retry Rate} \% = \frac{R_{\text{retried units}}}{T_{\text{unique units}}} \times 100$$

$R_{\text{retried units}}$ : number of unique units that were processed more than once

$T_{\text{unique units}}$ : total number of unique units processed

While Retry Rate focuses on the proportion of unique units that required additional re-processing, a related term, "Retry Run Rate", looks at how many of the total test runs were from retry attempts rather than first-time runs for a given unit. The dashboard reports the Retry Rate metric — providing a clear view of how frequently units are being retried — and does not include Retry Run Rate directly. Thus, we'll only be going into Retry Rate in more detail below.

Examples

Example 1: Simple

In this example, we'll compute the Retry Rate for one station with a few re-processed units.

Each bar below represents a single station run. Units that appear more than once were retried.

• Unique Units: 4
• Retried Units: Out of 4 units, 2 units were attempted more than once.

$$\text{Retry Rate} \% = \frac{\text{count}\left\{\text{unit 2, unit 3}\right\}}{\text{count}\left\{\text{unit 1 ... 4}\right\}} \times 100 = \frac{2}{4} \times 100 = 50\%$$

Example 2: Complex

In this example, we'll compute Retry Rate for a station group consisting of stations A and B — processing overlapping sets of units in parallel. We'll explore how flows with different retry policies will affect the numbers.

Stations A and B process units in parallel. The diagram below shows how units flow through both stations over time — each block is one station run, and you can see which units were retried by looking for repeated unit IDs:

From each unit's perspective, the sequence of station runs looks like this — each row shows the stations a unit visited, in order:

Outcome:

Group 1 consists of Station A and Station B.

• Unique Units: 10

• Retried Units: Out of 10 units, 6 units were attempted more than once.

  $$\text{Retry Rate} \% = \frac{\text{count}\left\{\text{unit 2 ... 7}\right\}}{\text{count}\left\{\text{unit 1 ... 10}\right\}} \times 100 = \frac{6}{10} \times 100 = 60\%$$
  • Station A:
    • Unique Units: 7
    • Retried Units: Out of 7 units, 5 units were attempted more than once. $$\text{Retry Rate} \% = \frac{\text{count}\left\{\text{unit 2, unit 4 ... 7 }\right\}}{\text{count}\left\{\text{unit 1 ... 7}\right\}} \times 100 = \frac{5}{7} \times 100 = 71.4\%$$
  • Station B:
    • Unique Units: 8
    • Retried Units: Out of 8 units, no units were attempted more than once. $$\text{Retry Rate} \% = \frac{\text{count}\left\{\text{ }\right\}}{\text{count}\left\{\text{unit 3 ... 10}\right\}} \times 100 = \frac{0}{8} \times 100 = 0\%$$

In this example, Station A shows a significantly higher retry rate, suggesting potential instability or inconsistency in its test setup, fixture, or process parameters. Comparing retry rates at both the group and station levels helps highlight where variability is occurring — whether isolated to a single station or systemic across the line.