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.

Unit Flow:

• 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 = 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.

Station Group 1:

• Station A:

• Station B:

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 = 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 = 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 = 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.