---
title: "Set cycle times and downtime filters"
description: "Three numbers on an operation decide whether counts and goals match the floor: the ideal cycle time in the Ideal Operation Cycle Time column of the Parts List at /production?select=parts_list, the quantity per cycle in QTY/OP, and the continuous downtime filter percentage, which only Continuous Analysis operations carry and which accepts 0 to 200%. Production rate is the same number inverted, 60 divided by the cycle in seconds. The Calculated Goal on Shift Production, the parts gauge and the hourly bars are all derived from the ideal cycle time, and none of them can be set anywhere else."
category: "Set up parts and operations"
source_url: "https://www.iotflows.com/docs/production/cycle-times-and-filters/"
---
# Set cycle times and downtime filters

The three numbers that decide whether your counts and your goals match the floor.

Every goal, pace and gauge in Production is derived from figures you type onto an operation in the Parts List, at `/production?select=parts_list`. Three of them carry the weight: the ideal cycle time, the quantity per cycle, and the continuous downtime filter. Counts still arrive when these are wrong, measured against the wrong target, which is much harder to notice.

**Before you start**

- A part with at least one operation. See [Create parts and operations](/docs/production/parts-and-operations/).
- The operation's detection algorithm set, because it decides which of these fields appear and whether the count itself reads the cycle time. See [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/).

## Set the ideal cycle time
*Ideal cycle time* is how long one good cycle of this operation takes when the machine is running well. You enter it. Nothing measures it for you.

Three figures in the product are called a cycle time, and only one of them is yours to type:

| Number | Source | Used for |
|---|---|---|
| **Ideal** | Typed here, on the operation | The shift goal, the hourly goal and the parts gauge. Continuous Analysis also divides running time by it to produce the count |
| **Goal** | Derived from the ideal cycle time and the machine's uptime goal. See [Set OEE and utilization goals](/docs/monitoring/oee-goals/#machine) | The threshold the actual figure is colored against: green at or below it, red past it |
| **Actual** | Measured from detection events while the machine runs | What the machine really did, on the Assets page, the machine page and Shift Production |

To set the ideal:

1. Open **Production**, then the **Parts List** tab at `/production?select=parts_list`.
2. Click into the operation's **Ideal Operation Cycle Time** cell.
3. Type the cycle across the four boxes: `hr`, `min`, `sec`, and after the decimal point, hundredths of a second. A 20-second molding cycle is `0 : 0 : 20 . 0`. A half-second press stroke is `0 : 0 : 0 . 50`.
4. On a **Discrete Analysis** or **Discrete w/o Merge** operation, set the tolerance percentage in the box beside it. Hover it to read the **Cycle Time Range** it produces, for example `(00:01:48 - 00:02:12)` for a 2-minute cycle at 10%.
5. Click elsewhere. The cell saves on its own, with no Save button.

The hour box takes a single digit, minutes and seconds stop at 59, and the tolerance runs 1 to 99% and falls back to 10% if you clear it. **Continuous Analysis** and **Counter** operations carry no tolerance box and save with the tolerance at zero.

**Set the ideal cycle time to the best sustainable cycle, not the fastest one ever recorded.** Every pace figure on the site is measured against it, so a heroic number makes a normal shift look like a failure and trains people to ignore a red gauge. Time 10 to 20 consecutive cycles on a good day and use that.

![The Algorithm and Ideal Operation Cycle Time columns of one Parts List operation row, a Counter operation, with two numbered violet callouts: 1 on the four cycle-time boxes reading 0 hr, 0 min, 1 sec and 33 after the decimal point, and 2 on the swap control beside them, labeled H:M:S over an up-down arrow, which restates the same cycle as a rate in ops per minute](/images/production/prod-cycle-01.webp)

*Ideal cycle time and production rate are the same number stated two ways.*

## Production rate is the same number
*Production rate* is the ideal cycle time turned over: parts per minute instead of seconds per part.

```
production rate = 60 ÷ cycle time in seconds
```

A 20-second cycle is `3.0 ops/min` and a half-second stroke is `120.0 ops/min`. The unit is the operation's own **OP UNIT** label, which defaults to `ops`. See [Unit and quantity per cycle](/docs/production/parts-and-operations/#units).

On a **Counter** operation, and only there, the Parts List cell carries a swap control beside the boxes. Click it to switch the cell between `H:M:S` and the rate, type the rate, and the cycle time is written back from it. The two figures can never disagree, because only the cycle time is stored.

Everywhere else the rate is a reading rather than an input. Shift Production and the machine page show **Ideal**, **Goal** and **Actual** together, with one arrow that flips all three between a cycle time and a rate.

**Enter whichever number your plant already quotes.** A press rated at 120 strokes a minute is easier to type as a rate than as `0.50` seconds, and a molder quoted at a 22-second cycle is easier to type as a cycle. On a Counter operation you have the choice; on the other three, convert once and type the cycle.

## Set quantity per cycle
*Quantity per cycle* is how many parts one detected cycle of this operation yields. It is the **QTY/OP** cell on the row, with its own unit label beside it, which defaults to `made`. The field reference is on [Unit and quantity per cycle](/docs/production/parts-and-operations/#units).

It belongs on this page because **the cycle time is per cycle, never per part**. A two-cavity mold with a 22-second shot makes two parts every 22 seconds: the cycle time stays `22.0` and QTY/OP goes to `2`. Halving the cycle time instead gets the part count right and every rate, goal and gauge wrong.

The number reaches three places:

- **Part counts** are the cycle count multiplied by it. A four-cavity mold left at `1` reports a quarter of its real output.
- **Gauges reported in ops** divide it back out, which is the second gauge Shift Production draws beside Progress on any operation whose cycle yields more than one part. See [Read the board](/docs/production/shift-production/#board).
- **A work order's time estimate** divides the pieces ordered by it. 500 pieces at a 45-second cycle, 2 per cycle, estimates `3 hrs 8 mins` and shows its working as `Estimated from 45s cycle x 500 pcs at 2/cycle`.

**Leave QTY/OP at 1 unless the machine really yields more or fewer parts per cycle.** It is the only field on the row that scales the answer, so it is the first cell to check when a count comes out doubled or halved, and the last one to change when a count looks close.

![The Description and QTY/OP columns of one Parts List operation row, with the QTY/OP field ringed in violet: it holds the value 2 with the unit label made beside it, and the description beside it reads 2-cavity mold, black ABS](/images/production/prod-cycle-02.webp)

*Quantity per cycle. A two-cavity mold produces two parts per cycle.*

## Set the continuous downtime filter
A *downtime filter* is a share of the ideal cycle time under which a stop is counted as running time instead of as downtime. It exists so that brief in-cycle pauses on a machine that never fully stops do not fill the downtime record.

Only **Continuous Analysis** operations have one. That algorithm produces its count by dividing running time by the cycle time, so a pause counted as downtime is also a pause that costs parts. See [Continuous Analysis](/docs/production/choose-an-algorithm/#continuous).

The **Downtime Filter** column appears on a part only when at least one of its operations runs that algorithm, and inside that part only the Continuous rows carry an editable cell. On a part whose operations are all discrete, the column is not on the table at all.

1. Click the **Downtime Filter** cell on the Continuous Analysis row.
2. Type a percentage. The field accepts `0` to `200` and clamps anything higher as you type.
3. Click elsewhere to save. Hovering the cell reads back what the current number does.

Read the percentage as a length of time, because that is what it becomes: 150% of a 20-second cycle is a 30-second window, and every stop shorter than 30 seconds is converted to uptime.

Diagram: Two horizontal bars covering the same three minutes. The upper bar, labeled ideal, one cycle every 20 seconds, is divided into nine equal cells and annotated nine cycles in three minutes. The lower bar, labeled actual, what the sensor saw, is mostly running and is broken by three pauses: an 8 second pause and a 26 second pause, both drawn in violet and marked becomes uptime, and a 48 second pause drawn in gray and marked stays downtime. A dashed violet line inside the 48 second pause marks where the filter window ends, 30 seconds in. The actual bar is annotated under 5 cycles in the same 3 minutes. A key below reads: filter window, 150 percent of a 20 second cycle, equals 30 seconds. A closing line reads: a stop shorter than the window is counted as running time. The 48 second stop runs past it, so it stays downtime.

*Ideal cycle time against actual, with the continuous downtime filter window marked. Pauses inside the window are not counted as stops.*

Because the window is a multiple of the cycle time, changing the cycle time moves the filter with it. An operation re-timed from 20 to 40 seconds at 150% goes from hiding 30-second stops to hiding minute-long ones without anybody touching the filter.

**You do not need a downtime filter on a machine that runs continuously.** The filter exists to stop short in-cycle pauses reading as stops, and a truly continuous process has none to hide, so all the filter does there is hide real ones. Start at `0`, watch the [Downtimes report](/docs/monitoring/downtimes/#table) for a week, and raise it only if that list fills with pauses nobody on the floor would call a stop.

Short stops on the other three algorithms are handled on the machine instead, by **Downtime Threshold** with **Treat short downtimes as uptime**. See [Handle short stops](/docs/hardware/calibrate-senseai/#short-stops).

## Where the shift goal comes from
The **Calculated Goal** on Shift Production is derived from the ideal cycle time you set here. That page reads the number and cannot set it. There is no per-operation goal override anywhere in the product.

```
Goal = (Shift Duration - Expected Downtime) / Cycle Time
```

Expected downtime is the historical average for that operation and machine. See [Where the goals come from](/docs/production/shift-production/#goals).

Two more numbers follow the same cycle time. The parts gauge, *performance*, measures actual output against what the ideal cycle time implies over the window, so it moves the moment you change the ideal. The hourly bars carry a per-hour goal derived from the same figure and the machine's uptime goal.

See [Performance](/docs/monitoring/metrics-reference/#performance) and [Production metrics](/docs/monitoring/metrics-reference/#production).

The downtime filter feeds a different pair. Converting a stop to running time raises [uptime](/docs/monitoring/metrics-reference/#uptime) and lowers [downtime](/docs/monitoring/metrics-reference/#downtime) for that machine, so a filter set too high flatters the board.

## Cycle settings reference
| Field | Unit | Affects | Set too high | Set too low |
|---|---|---|---|---|
| **Ideal Operation Cycle Time** | Hours, minutes, seconds, hundredths | The shift goal, the hourly goal, the parts gauge, the filter window. On Continuous Analysis, the count itself | Goals are met on a bad shift, the parts gauge sits above 100%, and Continuous Analysis undercounts | Goals are unreachable, the gauge reads red on a good shift, and Continuous Analysis overcounts |
| Tolerance, beside the cycle time | Percent, 1 to 99. Discrete algorithms only | The **Cycle Time Range** drawn around the ideal | The range covers cycles that are not this operation | The range excludes cycles the machine really runs |
| **QTY/OP** | A count, fractions allowed | Part counts, the ops gauges, work order time estimates | Counts read high by the same factor | Counts read low by the same factor. A four-cavity mold at `1` reports a quarter of its output |
| **Downtime Filter** | Percent of the cycle time, 0 to 200. Continuous Analysis only | Uptime and downtime on the machines running that operation | Real stops are absorbed into uptime and never reach the Downtimes report | Brief in-cycle pauses fill the downtime record |

## Check your numbers against the floor
Check the numbers you typed against what the machine reports, once it has run the operation for an hour or more.

1. Open the machine's row on the **Assets** page and read the **Cycle time** it reports beside the operation. That figure is measured from detection events, not from anything you entered. See [Review the detected cycle time](/docs/production/auto-detect-operations/#cycle-time).
2. Compare it with your ideal. A figure within a few percent means the ideal is a fair target; a figure half or double the ideal is an algorithm problem rather than a cycle-time one.
3. Open **Shift Production** at `/production?select=part` and read **Ideal**, **Goal** and **Actual** together on the operation's row.
4. Check the parts gauge. A gauge above 100% means the machine beat an ideal cycle time that is set too slow, not that it outran physics.
5. Open the [Downtimes report](/docs/monitoring/downtimes/#table) and confirm that real stops are in the list and short in-cycle pauses are not. That is the filter's verdict.

Validate the count itself against a hand count rather than against a total that looks about right. The procedure and its accuracy bands are on [Validate your choice](/docs/production/choose-an-algorithm/#validate).

**When a change does not save**, the cell puts the old value back and the dashboard raises the server's message as a toast. Retype the value once; a message that returns is a number being rejected, not a number being lost.

Counts that stay wrong after all three of these numbers check out are on [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/).

## See also
- [Troubleshoot inaccurate part counts](/docs/production/troubleshoot-part-counts/)
- [How each metric is calculated](/docs/monitoring/metrics-reference/#cycle-time)
- [Set OEE and utilization goals](/docs/monitoring/oee-goals/)
- [Track production against shift goals](/docs/production/shift-production/)
- [Choose a production tracking algorithm](/docs/production/choose-an-algorithm/)