Ask a plant floor how many seconds it takes to make one piece at a given process, and very few can answer on the spot. Even when an answer comes back, nobody can say whether it reflects Monday morning, the night shift, or the run immediately after a changeover. Cycle time measurement is the starting point of every improvement activity, yet in most factories it still depends on someone standing there with a stopwatch, which leaves it short on both accuracy and freshness. This article sets out what to measure, why manual timing eventually breaks down, and how far IoT can automate the job, framed around the realities of Japanese-affiliated plants in Thailand.
What Cycle Time Really Measures and How It Differs from Takt Time and Standard Time
Defining cycle time
Cycle time is the net time it takes one process to turn out one unit, from start to completion. Load a workpiece into a machine, and the elapsed time until processing finishes and the piece is ready to hand to the next process is one cycle.
The definition is simple, but almost every disagreement over the numbers on a shop floor comes down to where “start” and “completion” are placed. Does the clock start when the operator picks up the part, or when the machine begins cutting? Does it stop when machining ends, or when the next person takes the piece? On identical equipment, different boundaries produce different numbers. Measuring cycle time therefore begins as an agreement exercise — the plant has to decide, once, where one cycle begins and ends.
The second point worth fixing early is that cycle time belongs to a process, not to a line. Process A, process B, and process C each have their own value, and the longest of them sets the pace of the whole line. That is the bottleneck. Which process is the bottleneck only becomes visible when every process is measured to the same standard. Measuring one process tells you nothing about the order in which to improve.
How cycle time differs from takt time
Takt time is derived from customer demand. Divide the available operating time in a day by the quantity required that day, and you get the pace you must hit — one piece every so many seconds — to keep up.
The decisive difference is where the number comes from. Cycle time is an observed value; walk the floor and you can measure it. Takt time is a calculated target; you can watch the floor all day and it will never appear. When orders increase, takt time shortens, and a line that has not changed at all suddenly cannot keep pace.
What matters for management is the relationship between the two. We will call takt time minus cycle time the takt gap. Where that value is positive, the process has headroom against demand. Where it is negative, the process cannot meet demand as it stands. Improvement priorities start with the processes showing a negative takt gap — the ones where cycle time already exceeds takt time.
Standard time and lead time
Standard time is a value set in advance — the time a worker of defined skill level needs to produce one unit under defined working conditions. It is normally built by taking the net hands-on time and adding an allowance for fatigue and unavoidable workplace interruptions. It feeds costing, labour estimates, and headcount planning. Because a person sets it, it is a different kind of number from an observed cycle time. For manual work, standard time runs longer than the measured cycle time because of that allowance. On machine-paced processes, however, equipment cycle time can exceed the human standard time, so the two cannot be ranked by a simple rule.
Lead time is the total elapsed time from order to shipment, or from material release to finished goods. It includes waiting, transport, and time queued for inspection, not just processing. When the lead time runs far longer than the sum of the cycle times, the gap is time spent not making anything, and that is where work-in-process piles up.
The four terms line up like this.
| Term | What it represents | How it is determined | Main use |
|---|---|---|---|
| Cycle time | Net time for one process to produce one unit | Observed on the floor | Bottleneck identification, capacity, verifying improvement |
| Takt time | Pace required to meet demand | Operating time divided by required quantity | Production planning, staffing, line design |
| Standard time | Reference time per unit under defined conditions | Net time plus an allowance | Costing, labour estimates, headcount planning |
| Lead time | Total elapsed time across all processes | Measured including waiting and transport | Delivery quotations, inventory decisions |
Debating improvement while confusing these four terms is how improvement teams end up talking past each other. “Slower than standard time” is a statement about a reference value. “Not meeting takt time” is a statement about demand. The first usually points to work method or operator skill; the second usually points to equipment capability or staffing. Because the two send you looking in different places, aligning the vocabulary comes first.
Why Stopwatch Cycle Time Measurement Eventually Runs Out of Road
The error built into manual measurement
Traditional cycle time measurement has been visual timing with a stopwatch. It needs no equipment and can start tomorrow morning, which is a real advantage. Its weakness is that the method itself introduces error, so accuracy never quite settles. Video recording and later analysis is the other classic approach — it breaks a cycle into fine motion elements, but filming and analysis take effort, which makes it poorly suited to measuring continuously.
The error creeps in at a few identifiable places.
The boundary shifts from person to person. Where the button gets pressed is ultimately a judgement call. There is a gap between the moment the cutting noise stops and the moment processing is genuinely complete, and that gap changes when the observer changes.
The sample is small. Standing at the machine, you might realistically capture a few dozen cycles. But cycle time is a distribution. An average drawn from a few dozen observations cannot rule out that you happened to sample a good hour.
Whole time bands are missing. Measurement happens on day shift, on the days someone set aside time for improvement work. Night shift, the ramp-up after a break, the first pieces after a material changeover — exactly the periods with the widest variation — leave no data behind.
Being watched changes the work. With someone standing behind the operator holding a stopwatch, the pace changes. What you record is the value you get while someone is watching, not necessarily the everyday value.
The trap of looking only at averages
What manual timing yields is, in most cases, an average of a few dozen cycles. But the raw material for improvement is not the average — it is the shape of the variation.
Two processes can both average 40 seconds. In one, every cycle falls between 38 and 42 seconds. In the other, some cycles run 35 seconds and some run 70. The countermeasures are completely different. The first is a question of making the process itself faster; the second is a question of eliminating whatever occasionally costs 70 seconds. The second usually holds the larger improvement opportunity, yet with nothing but an average you never even learn that 70-second cycles exist.
Variation shows up in more forms than the occasional long cycle. Longer only with one operator. Longer only with one material lot. Longer only late in the afternoon. Conditional patterns like these emerge only when near-complete data is sliced by condition. With a sample of a few dozen, every slice leaves you with a handful of cycles per group and nothing you can act on.
Why manual measurement does not hold up in Thai plants
At Japanese-affiliated manufacturers with plants in Thailand, the limits of manual measurement tend to surface earlier than at the parent plant in Japan. What follows is not backed by statistics — it is a summary of patterns we hear about repeatedly on site.
First, the number of Japanese expatriate staff is typically smaller than at a domestic head-office plant. Having that limited group walk every line on a regular schedule with a stopwatch is physically difficult, so measurement drifts into “we measure when something looks wrong.” Data gathered only when something already looks wrong cannot catch a trend of gradual deterioration early.
A multilingual floor adds to it. Thai-speaking operators, workers from Myanmar and Cambodia, and managers who want their reports in Japanese. Passing “how many seconds is this process taking right now” verbally through that chain rounds off the information at every handoff. Once the number lives in a system, everyone sees the same value regardless of language.
Shift handover loss is equally hard to avoid. What happened on the previous shift travels by word of mouth and a paper daily report. “It was a bad day” survives; which hours were slow, and by how much, does not. The next shift walks into the same problem in the same way.
Relatively high turnover undermines the premise manual measurement rests on. Know-how about how to measure tends to sit with individuals, and when the person who was doing the measuring leaves, the measurement stops. When the measurement is built into a system, the numbers keep accumulating no matter who holds the role.
How IoT Automates Cycle Time Measurement
Deciding what counts as one cycle
Designing automatic measurement starts with choosing which signal marks the boundary. Select hardware before settling this, and you will not be able to explain what the numbers mean later.
Three approaches cover most cases.
Use the cycle-complete signal. Take the signal the equipment emits when it finishes one cycle. Because it matches the machine’s internal sequence, it gives the most straightforward value.
Detect the workpiece passing. Use a photoelectric or proximity sensor to detect the product leaving the process. This works when you cannot touch the equipment itself.
Extract the period from the motion. Cut one cycle out of a continuous waveform such as current draw or vibration. This is the method for older equipment that exposes no usable signal.
The choice slightly changes what you are measuring. A cycle-complete signal is close to net machining time; outlet detection includes unloading. Choosing the option that matches the unit the plant actually wants to compare is what makes later discussions possible.
Three routes for capturing the signal
Equipment on a real floor spans different vintages and different makers. There is no single method that covers all of it, so the route is chosen machine by machine.
| Capture route | Suited equipment | Data obtained | Points to watch |
|---|---|---|---|
| PLC data integration | Equipment with a PLC in the panel and a documented communication spec | Completion signals, operating mode, alarm codes, production counts | Requires agreement with the machine builder and a check on warranty conditions |
| Add-on sensors | Equipment with no communication capability, mechanical devices | Passage detection, cycle counts, running versus stopped | Mounting position and detection conditions drive the accuracy |
| Signal tower and contact output | Older equipment with a stack light or dry contacts | Transitions between running, stopped, and fault | State granularity is coarse and gives no root cause |
The third route, reading the stack light, is widely used as a realistic way to start visualising a floor without stopping existing equipment. The design thinking behind it is set out in detail in our article on signal tower data collection for Thai factories, which is worth reading if your target machines have no communication interface.
It is entirely normal for all three routes to coexist in one plant — PLC integration on the newest line, add-on sensors on the previous generation, stack lights on the oldest machines. What matters is that whichever route the signal takes, it lands in the database as cycle time in the same format. If the meaning of the number changes with the capture route, cross-line comparison becomes impossible.
What the IoT gateway does
A signal pulled off the floor is not usable for analysis as it stands. The IoT gateway is what bridges that gap.
An IoT gateway accepts the assorted communication standards on the equipment side, applies a timestamp, converts values into the required units, and relays them to an upstream server or cloud. In manufacturing data collection design, timestamping is where problems usually start. If process A and process B are recorded against separate clocks, correlating them scrambles the sequence of events. Unifying time at the gateway is what determines the accuracy of everything downstream.
The gateway’s other job is buffering when communication drops. A factory network is not always stable. If the gateway can store data temporarily, it can send the backlog once the link recovers and avoid gaps. With data like cycle time, where continuity carries meaning, whether the middle is missing decides whether analysis is possible at all.
Combining IoT sensors, PLC data integration, and an IoT gateway produces a state in which cycle time and equipment status for every process are collected automatically and in real time, ready to analyse. Where manual timing gave you a few dozen cycles on one day in one time band, automatic measurement records every cycle, across every time band, without interfering with the work. That difference changes what the analysis stage can do.
Where to put the collected data
Where the data lives is also a design decision — on a server inside the plant, or in the cloud. If the site is in Thailand and head office in Japan also wants visibility, doing first-stage processing locally and consolidating to the cloud tends to be the easier architecture to run. The global remote monitoring and control market is forecast at USD 32.41 billion in 2026, growing at a compound annual rate of 6.7% from 2025 to 2030, so demand for viewing floor data across sites is itself expanding.
That said, there is no need to aim for a company-wide integrated platform from day one. Get cycle time on one line captured correctly, and reach the point where you can make improvement decisions from it. Rolling out horizontally after that shape has settled keeps the loss small if something turns out to be wrong.
Connecting the Data to Downtime Cause Analysis and Improvement
Look at the shape of the variation first
Once automatic measurement starts, the first thing that becomes visible is not the average but the distribution. Plot several thousand cycles from one process as a histogram and you will often find not one peak but two or more.
When the peaks separate, it usually means substantially different work is being recorded under one process name. Material at hand versus material to fetch. With a fixture change in the cycle versus without. With a first-article inspection versus without. Count them separately and the variation inside each group shrinks, which makes the improvement target concrete.
A single average cannot make that separation. A target of “take a 40-second average process down to 38 seconds” is, in reality, being set against a process that mixes 35-second work with 70-second work, and it does not say which of the two you intend to shorten. Looking at the distribution is the prerequisite for scoping improvement themes correctly.
Record why the long cycles were long
To learn what was happening in the right-hand tail — the abnormally long cycles — you need downtime records. Cycle time data alone will never tell you why one cycle took 70 seconds.
In practice, you add a mechanism that records a reason code whenever a stoppage occurs. Waiting for material, fixture change, equipment fault, quality check, upstream delay, and so on. It works better not to make the categories too fine at the start. Beginning with roughly ten and subdividing only the categories that actually turn out to be frequent keeps the input burden on operators low, which is what gets the data filled in.
Cross-referencing reason codes against cycle time gives downtime cause analysis a numerical basis. The cause with the highest number of stoppages and the cause with the largest total stopped time are not necessarily the same. A cause that is infrequent but long each time gets missed if you only count occurrences. Sorting by total time is what makes the priority order meaningful.
The related question of how much loss accrues between a stoppage occurring and somebody acting on it is covered in factory system monitoring and the cost of detection delay. Cycle time measurement is about how long something took; that article is about how many minutes passed before anyone noticed. The two work as a pair.
Count setup time separately
Automating cycle time measurement also reveals the reality of setup time, because the break in the cycle time record around a product changeover is the setup period itself.
The important discipline here is not to mix setup time into machining cycle time. Blend them, and a day with many changeovers looks like a day when the process got slower, which leads to the wrong judgement. Count setup as setup, and manage it on both the number of changeovers and the time per changeover.
Reducing setup time itself is covered in our article on changeover and setup time reduction, which argues that improvements fail to stick because the unit of measurement is too coarse. Once automatic measurement leaves a second-by-second record of the changeover window, the fine-grained breakdown discussed there becomes genuinely possible.
Convert it into a gap against plan
Cycle time data is useful on its own, but it becomes something the floor acts on when placed alongside the plan. How many units should be complete by this hour, how many actually are, and what the gap is. Only in that form does it become clear what to do next.
The display and operating design for that is covered in production progress monitors and turning plan gaps into action. Cycle time measurement supplies the underlying data that makes the plan gap computable. Put another way, installing a progress monitor without cycle time in place leaves the displayed numbers resting on weak foundations.
Implementation Steps for Automated Cycle Time Measurement
Establish the current state
Start by putting into words which process has a problem you cannot see. A request to “visualise the floor” is not something you can select hardware against. Is the issue that you do not know where the bottleneck is, that you cannot explain the variation, or that the night shift is a blind spot? The more specific the pain, the narrower the data requirement.
At the same time, inventory the target equipment — year, maker, panel contents, whether a communication interface exists, whether a stack light exists. That list becomes the selection table for capture routes later.
Fix the unit of measurement
Decide, as a plant, where one cycle starts and completes. Skip this and install hardware, and you will inevitably argue about how to interpret the resulting numbers. Get production engineering, manufacturing, and quality to agree, and put it in writing.
Try it small
Rather than rolling out to every line, try one line or one process. The purpose is not to confirm that the hardware works — it is to confirm that the resulting data supports a decision. If a week of data lets you say “we should fix this specific thing at this process,” the design is usable. If data is accumulating but you cannot say anything, revisit the unit or the granularity.
Select the hardware
Choose sensors, gateways, and communication methods based on what the trial showed. Performance is not the only criterion. Can spare parts be obtained inside Thailand? Can a failed unit be swapped locally? Can local staff make configuration changes? A configuration that cannot be restored without shipping a part from Japan is a configuration the floor cannot recover on its own.
Accumulate the data
Widen the scope and let data build up. What to check at this stage is missing data and clock drift — any window lost to a communication drop, any data lost to a gateway restart. Confirm the data is trustworthy before moving into analysis.
Analyse and improve
Look at the distribution, cross-reference the reason codes, set priorities, and act. Then measure cycle time after the countermeasure using the same method and confirm the effect. This is where the real value of automatic measurement sits. Manual timing always carries the suspicion that the before and after were measured differently; measure continuously through the same mechanism and the before-and-after comparison simply holds.
Make it stick
Improvement is not a one-off. Review the distribution weekly, catch signs of deterioration, and set the next theme. When that loop is turning, the implementation is complete. To avoid the common outcome of building a dashboard and stopping there, it helps to write down as an operating rule who looks at what, and when.
How to Think About Cost and Payback
There is no single market price
The cost of automated cycle time measurement varies enormously with scale and with the state of the existing equipment. Even for an identical requirement of “visualise ten machines,” a case where all ten have a PLC with a documented communication spec and a case where none have any interface and all ten need add-on sensors involve completely different amounts of installation work. For that reason we will not assert a general market price here.
Understanding what drives the variation does, however, sharpen how you read a quotation.
| Cost driver | Pushes cost down | Pushes cost up |
|---|---|---|
| Equipment communication | PLC present with a documented spec | No interface, new sensors required |
| Number of machines | Identical models in a row, one design reused | Mixed models needing per-machine design |
| Factory network | Wired or wireless already installed | Cabling work or extra access points needed |
| Downtime allowance | Can be installed while running | Line must be stopped for installation |
| Required granularity | Running versus stopped is sufficient | Second-level cycle time plus reason codes needed |
The more items that land in the right-hand column, the larger the initial cost. Conversely, when a quotation comes in higher than expected, asking which of these drivers is responsible will show you what can be trimmed and what cannot.
Explaining the payback
Justifying the investment means converting saved time into money. Three lines of reasoning are available.
Extra output from shortening the bottleneck. Shave a second off the bottleneck and the capacity of the whole line rises. Whether that converts into revenue depends on whether demand exists. Where orders are backing up, the effect flows through cleanly.
Reduced downtime. This is the time recovered by eliminating the frequent causes identified in downtime cause analysis, and it is valued from the quantity that could have been produced during those stoppages.
Less effort spent on measuring. The hours spent on stopwatch timing and on compiling daily reports disappear. The monetary scale depends on how the floor operates, but this saving is certain to occur, with the side benefit that the staff member’s time moves into improvement work itself.
The caution is not to simply add these three together. Double-counting the same hour once as extra output and again as reduced downtime is a common error. Extra output is also conditional — it holds only where demand exists, and cannot be booked on an assumption of flat demand. Check at the estimating stage whether the conclusion reverses when a premise fails.
For the wider cost structure and payback logic of multi-site IoT investment, our article on overseas plant IoT implementation cost and payback in five layers breaks the spend down layer by layer, which is useful when you are preparing a budget document.
Frequently Asked Questions
What methods are available for measuring cycle time?
Broadly three — visual timing with a stopwatch, video recording analysed afterwards, and automatic collection from equipment signals or sensors. Stopwatch timing can start immediately but the value moves with the observer’s judgement and timing. Video analysis breaks work down to fine motion elements but takes effort to analyse and is not suited to continuous use. Automatic collection requires design work and hardware up front, but once running it accumulates records without human effort. A practical split is visual or video for a one-off work study, automatic collection when cycle time is to serve as an ongoing management metric.
How much does automated IoT measurement cost?
It varies with the number of machines, whether existing equipment has a communication interface, whether the plant network is in place, and how granular the data needs to be, so no single market price can be quoted. The drivers are set out in the cost section of this article. Preparing a list of target equipment with year and communication specification before requesting a quotation narrows the price range much earlier. Starting with one line before expanding lets you confirm that data can genuinely be captured from your own equipment while keeping the initial outlay small.
Can cycle time be measured on old equipment with no communication function?
Yes. Even where PLC communication is impossible, you can fit a photoelectric or proximity sensor at the process outlet to detect product passing, read running and stopped states from a stack light or dry contact output, or extract the motion period from changes in current draw. The more legacy equipment a plant has, the more the design becomes a combination of these add-on methods. Choosing methods that require no modification to the machine and no production stoppage to install also matters for getting the floor to agree to them.
Should takt time or cycle time be the management metric?
They serve different roles, so you watch both side by side rather than choosing one. Takt time is the target pace calculated from demand; cycle time is the actual capability of the floor. In day-to-day management you compare each process’s cycle time against takt time and prioritise the processes that exceed it. That comparison, however, assumes cycle time has been measured across enough cycles and enough time bands. Comparing an average of a few dozen manual readings against takt time can easily lead to the wrong call.
How long should we allow for implementation?
It depends on scope, but planning is easier if you separate the one-line trial from the company-wide rollout. In the trial phase, establishing the current state and agreeing the unit of measurement usually takes the most time, while the physical installation finishes quickly. What tends to be underestimated is the time it takes for the floor to get used to acting on the data. The real completion point is not when the hardware starts running — it is when a weekly meeting that reviews the numbers and decides the next move is up and running.
Summary
Cycle time measurement is the entrance to improvement work, and in most factories it is also the crudest part of it. Stopwatch timing moves with the observer’s judgement, and the number of cycles and time bands you can cover is limited from the start. Video analysis breaks work down more finely but is not suited to continuous measurement. What either yields is an average over a limited sample, which never reveals the shape of the variation that improvement actually feeds on.
Put in a manufacturing data collection setup that combines IoT sensors, PLC data integration, and an IoT gateway, and that constraint lifts. With the distribution visible, improvement themes can be scoped correctly; cross-referenced against downtime reason codes, downtime cause analysis gains a numerical basis. Setup time can be counted separately, and the same data feeds the calculation of the gap against plan.
The sound sequence is not to aim at a company-wide platform immediately, but to narrow the scope, fix the unit of measurement, confirm that the data supports decisions, and then expand. Because cost swings so widely with the state of the equipment, having the equipment list ready in advance moves the evaluation along much faster.
Which machines in a Thai plant can yield which signals, and how to carve out the first line, are exactly the points where the decision often stalls. At TOMAS TECH we start by listening to the state of your existing equipment and laying out the realistic capture routes and a workable sequence. You are welcome to get in touch even at an early exploration stage, before any concrete implementation plan is fixed — please reach us through our contact page.
References
- What is cycle time – SATFAQ DX Column
- Cycle time fundamentals – i-Reporter Column
- Differences between cycle time, takt time and lead time – Engineer Education
- Cycle time measurement methods and their limitations – tebiki Genba Improvement Lab
- Takt time, cycle time and lead time – HANCHO Column
- How to approach factory IoT implementation – Yachiyo Solutions
- Adoption of IoT in manufacturing and how to implement it – Shikumika
- Remote monitoring and control global market report – Global Information
