Factory System Monitoring 2026 | Detection Time Drives the Loss

In a factory, the hours during which nobody realised a server was down cost more than the outage itself. When we visit Japanese-owned plants in Thailand and talk about incidents, the conversation almost always converges on causes. Which device failed, which setting was wrong. Yet what actually determines the loss on the shop floor is not the cause but the time between the moment something went wrong and the moment somebody noticed. In this article we take a metal parts machining plant in Ayutthaya Province as a model case, count 14 incidents in a year, and calculate honestly what it is worth in THB to cut detection time from 2.4 hours to 9 minutes. The conclusion, stated up front, is that faster detection alone does not recover the cost of monitoring. We then work through why monitoring is still worth doing.

In Factory IT, the Loss Comes From Late Awareness, Not From the Failure Itself

Incident reviews usually begin with root cause analysis. A disk failed, a power supply died, an update overwrote a setting. That discussion matters, because identifying the cause is what allows you to prevent a recurrence. But when the question is how much money that incident cost, the cause has almost no answer to offer.

What determines the size of the loss is the time the system was unavailable, and more precisely the portion of that time during which nobody knew. Recovery work itself takes as long as the severity of the cause dictates. Replacing a disk takes hours; rolling back a setting takes tens of minutes. That is a technical matter and hard to compress through effort alone. Time to awareness, on the other hand, is not a technical matter but a structural one. Change the structure and this part alone shrinks dramatically.

What we commonly see at Japanese-owned factories in Thailand is that incidents surface only when a user reports them. When the production management system stops responding, a shop floor operator first reloads the page a few times. If that fails, they ask the person at the next desk whether it works for them. Only after several people have confirmed that it is not just their own terminal does a message finally reach the administration department. An hour or two can easily disappear in that sequence.

The delay stretches further at night and at weekends. A server that goes down when nobody is using it stays down until the next morning shift. If it fails during the overnight batch window, the failure surfaces in the morning as “yesterday’s data is missing.” What is lost in that case is not the downtime itself but the slow start caused by being unable to issue the first production instructions of the day.

Surveys of large enterprises report very substantial losses per hour of system downtime, and Cost of IT Downtime from OutageCost.com cites findings from ITIC and the Uptime Institute along these lines. Those figures, however, come mainly from large organisations in the United States and cannot be transplanted onto a mid-sized Japanese-owned factory in Thailand. The industrial structure differs, and so does the scale of the transactions affected when systems stop. In this article we refer to that research only as background context, as evidence that studies at that level exist for larger organisations, and we use none of it in the model case estimate. The loss at your own plant has to be calculated from the conditions at your own plant.

The first input that calculation needs is a number for time to detection. A factory that does not have that number does not have the material required to judge whether monitoring is worth the investment.

What System Monitoring Actually Means — Availability, Performance and Logs

“System monitoring” is a convenient phrase in conversation but far too vague at the design stage, because what you watch determines entirely which kinds of abnormality you can catch. In practice we separate it into three types.

The first is availability monitoring. It checks only whether a device or service is alive. Send a request to a server at fixed intervals and confirm a reply. Call a web screen periodically and confirm a normal response. It is the simplest mechanism and the easiest to introduce. It catches only the state of having stopped completely, but complete stoppage is exactly the kind of incident that costs a factory the most, so on a cost-benefit basis it is the area to address first.

The second is performance monitoring. It watches the state of being alive but slow. CPU utilisation, free memory, free disk space, network bandwidth, database response time. You measure these continuously and raise a signal when the value departs from normal. Unlike availability monitoring, it requires a design decision about where to set the threshold. Get that decision wrong and you land in the classic failure described later, where alerts fire so often that nobody looks at them.

The third is log monitoring. It picks specific patterns out of the records that devices and software emit. Repeated authentication failures in a short window, disk read and write errors beginning to appear, a backup job terminating abnormally. Log monitoring is the only means of catching a system that has not stopped yet but is on its way to stopping. In exchange, deciding what to pick up is the hardest part, and it cannot be configured without understanding the internals of the target system.

The three differ in the timing at which they can catch something. Log monitoring works at the precursor stage, performance monitoring at the degradation stage, availability monitoring at the stoppage stage. Having all three is ideal, but budget and operating capacity impose real constraints, so priorities are needed. For a factory with no monitoring at all, availability monitoring is the standard starting point because its effect is the clearest and its configuration the lightest.

The scope also has to be settled. Is it enough to watch servers, or should network equipment be included? In factories, network-side incidents very often hit production directly, and when wireless access points drop, result entry from handheld terminals stops all at once. Wireless segments carry more sources of instability than wired ones, so it is realistic to build monitoring into the design from the beginning. We have covered the design of the factory network itself in key design points for building factory wireless LAN, which is worth reading alongside this article.

Something Has To Be Decided Before “Should We Outsource” — Dividing Roles With IT Outsourcing

When monitoring comes up, the first question is usually “can we outsource that?” With a Thai site typically running an IT function of 1 or 2 people, sometimes as a secondary duty, that is a natural reaction.

Part of what lies behind the reaction is the difficulty of hiring. According to a JETRO survey, 56.7% of Japanese-affiliated companies in Thailand described the shortage of IT personnel such as programmers as either very serious or somewhat serious, close to the 58.2% recorded across the Asia and Oceania region as a whole. The reasons given include the shrinking working-age population, weakening recruitment competitiveness against Thai conglomerates and infrastructure companies, and declining interest in Japanese employers following Japanese being overtaken by Korean as a second foreign language choice in university entrance examinations. In short, the solution of simply hiring more people to watch systems through the night is hard to reach for in the first place.

Still, putting the outsourcing question first usually stalls the discussion. Ask a provider for a quotation and they will invariably ask back which items are to be monitored, what the alert conditions should be, and which side performs first-line response. We have watched many evaluations stop dead at exactly that point. Whether to delegate is a question that can only be answered once the content of monitoring has been decided.

What is undecided is not delegation. Three things are undecided. What to measure, how far counts as abnormal, and who receives the signal once something is detected. If those three are settled, you get the same result whether you run monitoring in house or hand it to a provider. If they are not settled, either choice fails in the same way.

This article therefore does not address the delegation decision itself. For how far to push the three layers of monitoring, help desk and maintenance outside the company, and what the return on that looks like, see thinking about IT outsourcing at Thai sites layer by layer. This article stays one step earlier, on how monitoring itself is designed.

It is still useful to know how external monitoring services are tiered, because that vocabulary helps in dividing roles. As a Japanese domestic reference point, the MSP service comparison from ASPIC describes a tier that only delivers alert notifications, a standard tier that adds first-line response, and a higher tier that includes cause analysis and improvement reporting. The price levels are Japanese domestic ones and cannot be treated as Thai market rates, but the way the tiers are separated works well as shared language when deciding your own split. Do you receive notifications and respond yourself, or hand first-line response over as well? That line draws itself naturally once the monitoring design is finished.

The Fourth Layer Thai Factories Overlook — Power Quality

The previous section split monitoring into three types, but factories in Thailand have one more subject that deserves to be treated as an independent layer. Power quality.

It needs to be separate because pure IT monitoring cannot detect it. Availability monitoring reacts only after equipment has fallen over. While voltage on the supply side is sagging, the server is still running, so availability monitoring says nothing. Performance monitoring is no different, since CPU utilisation and free disk space have no relationship to voltage. Log monitoring eventually leaves a record saying the machine shut down on a power fault, but that is a record written after the event.

Thailand’s electricity situation has characteristics that differ from Japan. According to an explanation from Biz Info Log, momentary voltage dips are more common in Thailand than complete blackouts, and they occur several times a year even in urban Bangkok. Because a dip recovers within seconds, the lights merely flicker and production equipment keeps running. Servers and network switches, however, sometimes cannot ride through those few seconds and restart.

What makes this worse is that the dip itself leaves little trace. Nobody in the factory registers that there was a power failure, so a restarted server is logged as an unexplained event. The same thing repeats without any explanation, and each time the conversation becomes “the server is playing up again.” In reality it is not an equipment problem but a supply-side one.

That is why UPS and power-side monitoring have to be built in as a layer separate from IT monitoring. Specifically, what should be watched is how many times the UPS has detected an input anomaly, when transfers to battery occurred, the remaining capacity and health of the battery, and the state of the output. The UPS itself holds all of this, so fitting a network management card makes it retrievable. A UPS without such a card holds the information but cannot pass it outward. Checking that single point is already worth the effort.

Unless power quality is held as a fourth layer, the pattern of noticing only after something falls over does not change. However refined the IT-side monitoring becomes, incidents whose cause lies on the power side will always be detected after the fact.

Model Case | Counting Incidents at a Metal Parts Factory in Ayutthaya

From here we work with concrete numbers. What follows is a model case built on independent estimates and is not the data of a real company. Rather than the amounts themselves, please look at the procedure — where time is being lost and how that time is converted into money.

The premise is as follows. A Japanese-owned metal parts machining plant in Ayutthaya Province, Thailand, working in automotive parts, with 210 employees. The IT environment consists of 1 on-premises server hosting the production management system, 1 file server, and a plant network of 8 switches and 12 wireless access points. The production management system has 48 regular users who use it to check order information, issue work instructions, enter results and create shipping instructions.

No monitoring is in place. Incidents come to light when a user calls to say the system will not open. As Japanese-owned machining plants in Thailand go, this is an entirely standard situation.

The table below counts the incidents that occurred at this plant over one year, broken down by cause.

That is 14 incidents a year, a little over 1 a month. Some readers will find this higher than expected and others will find it unremarkable. The reason opinions divide is that nobody counts. At a plant that does not count, only the large incidents that stuck in memory register as incidents, and a small stoppage resolved in 30 minutes never enters the tally.

The breakdown by cause is what deserves attention. Software and equipment account for 6 incidents, while power quality accounts for 8. Dividing 8 by 14 gives roughly 57%, so more than half originate on the power side, and yet power almost never comes up when monitoring is discussed.

The seasonal skew is equally clear. Of the 14 incidents, 9 fall in the rainy season and 5 in the dry season. Splitting by cause shows where the skew comes from. The 6 software and equipment incidents divide 3 and 3, an even 50% either way, with no seasonality at all. The 8 power quality incidents divide 6 and 2, putting 75% in the rainy season. Effectively the entire seasonal skew comes from the power side.

Why Incidents Cluster in the Rainy Season — Voltage Dips and UPS Battery Ageing

The reason power-related incidents cluster in the rainy season lies in the weather itself. According to the PC Support Thailand column introduced by Thai Jiyu Land, squalls and thunderstorms between May and October, the Thai rainy season, cause frequent blackouts and voltage dips, raising the failure risk for servers and network equipment. Direct lightning damage is far less common than the momentary voltage swings that occur on the transmission network.

Seen from inside the factory, the phenomenon shows up in a very unhelpful form. The fact that a server restarted on the afternoon of a squally day is recorded, but there is no record anywhere of what the voltage was doing at that moment. The next day the person in charge reports that the server went down, and the manager instructs them to find out why. There is nothing to find out. What was never recorded cannot be investigated.

This is where the UPS becomes important. A UPS keeps supplying power through a dip, so if it is working properly the equipment does not fall over. That phrase, working properly, carries conditions. The internal battery must not have degraded, and the capacity must be sufficient for the actual load.

The same column recommends installing a UPS while pointing out that Thai ambient conditions accelerate battery ageing. In general, in an environment where room temperature sits around 30 degrees Celsius, a UPS battery tends to degrade within roughly 1 year, and an annual inspection and replacement check is treated as the guideline. Anyone applying a Japanese mental model in which batteries last several years will be caught out the moment a dip arrives, with equipment falling over despite a UPS being present.

Degraded batteries degrade quietly. The lamps on the UPS are lit and power is flowing. The shortfall in capacity is exposed only when the unit actually transfers to battery. In other words, the mere fact of having a UPS guarantees nothing about riding through dips. A UPS only starts working as an investment once battery health is included in what you monitor.

The model plant did have a UPS. Several years passed under the assumption that having one meant being covered, while servers kept going down during rainy-season dips. That is the background to the 8 power-related incidents. The problem was not that equipment had not been bought but that the condition of the equipment already bought was never being watched.

Why Detection Was Taking 2.4 Hours

At this plant, the average time between an incident occurring and the administration department becoming aware of it was 2.4 hours per incident. Breaking that down reveals several distinct stages.

The first stage is the time it takes a user to conclude that something is abnormal. When the production management screen will not open, users first suspect their own action or their own terminal. They restart, try another browser, and when that fails they get up and check with a colleague. Tens of minutes pass in that stage alone. For users who do not have the system open continuously, awareness comes only when they next try to use it, which pushes the gap from the actual failure time out further still.

The second stage is the reporting path. In most factories a system problem is passed first to the shop floor leader, who then contacts the administration department. If the leader is in a meeting, that adds delay. Chat as a channel is comparatively fast, but reliance on face-to-face conversation or telephone introduces waiting whenever the other party is unavailable.

The third stage is time of day. The 48 users do not all work the same hours. A failure during the lunch break is noticed after the break ends. A file server that stops during the night shift goes untouched until the following morning. Incidents occurring in these unused hours are what pull the average up. An average of 2.4 hours is the result of mixing cases noticed in 10 minutes with cases nobody noticed for 8 hours.

The fourth stage, and the one most often overlooked, is the state of having noticed but not reported. An operator decides that since the system is unusable they will write on paper and key it in later, and simply continues working. In their own frame the problem has been worked around, so there is no motivation to report it. The better a shop floor is at such workarounds, the less its incidents surface, and because they never surface no countermeasure is taken and the same thing happens again.

Looking across these four stages, they share one property. Every one of them depends on human judgement and human communication. Training people to be faster is possible in principle, but no amount of training allows a person to detect a server stoppage during a night shift when nobody is using it. That is the fundamental reason a monitoring mechanism is required.

How Far Monitoring Shortens Detection Time

With availability monitoring and threshold alerts in place, the average time to detection falls to 9 minutes, or 0.15 hours. The composition of those 9 minutes is quite clear.

A monitoring system confirms a response from its targets at fixed intervals. Shorten the interval and detection gets faster, but load on the monitored equipment and traffic both increase. In practice the check interval is typically set to something on the order of a few minutes, and rather than alerting on a single failed check, the system is configured to declare an abnormality only after several consecutive failures. Alerting on 1 failure produces constant false positives from transient network jitter. The product of the check interval and the consecutive-failure count is the main part of the detection delay.

To that you add alert delivery time, the tens of seconds between the abnormality being declared and the notification arriving by mail or chat. Together these settle at an average of around 9 minutes.

The reduction per incident is 2.4 hours minus 0.15 hours, or 2.25 hours. As a rate, 2.25 divided by 2.4 is approximately 94%. More than nine tenths of the time to awareness disappears. The size of that reduction is itself a reflection of how the starting state depended on user reports. A plant that already has some monitoring in place will not see anything like this effect from the same measure.

One point deserves care. What monitoring shortens is only the time to detection. The time from detection to recovery does not change. If a disk has failed, replacing it still takes what it takes, and if rolling back a setting takes 30 minutes, those 30 minutes remain. Monitoring is sometimes described as shortening total recovery time, but the accurate statement is that only the detection portion shortens, and blurring that distinction leads to the project later being judged as having produced no effect.

Equally, if there is no defined recipient for alerts at night and at weekends, faster detection does not start a faster response. A notification firing at 2 in the morning that nobody looks at until the working day begins leaves the effective detection time no better than a user report. That point belongs to the third axis of monitoring design, the notification route, discussed below.

How To Value One Hour of Shortened Detection

To put a figure on faster detection, you need to decide what one hour of undetected downtime costs. This varies enormously between plants, so we build it up from the stated conditions of the model case. Again, these are independent estimates.

To begin with, production does not stop dead the instant the production management system goes down. At this plant, any process that already has its work instruction in hand keeps machining. Results can be recorded on paper as a substitute. Roughly 30 minutes of paper-based operation is what the shop floor feels it can absorb.

The problem starts after that. Beyond 30 minutes, loading instructions for outbound trucks can no longer be issued. Shipping instructions are produced from the system, so when it is down there is no confirmation of which products go in how many boxes. As a result an arriving truck waits on site, and under the contract with the transport company that waiting time is billed.

The second element is the time of the people responding. When an incident occurs, an IT staff member and a production control staff member leave their normal work to deal with it. If it happens outside working hours, that becomes overtime.

The table below builds these two up from unit rates and quantities.

Truck waiting is 800 THB per hour per vehicle with an average of 1.2 vehicles affected, giving 960 THB per hour. Responders are 2 people at an hourly rate of 350 THB, giving 700 THB per hour. Added together, one hour of undetected downtime costs 1,660 THB.

Something has been deliberately left out of this build-up: the opportunity cost of production itself stopping. As noted, this plant can keep producing on paper for a limited period, so short stoppages do not affect output quantity. Long stoppages obviously would, but once you start assuming probabilities and magnitudes for those, the whole estimate becomes a stack of assumptions. Here we accumulate only the costs that certainly arise. Please read it as a deliberately conservative figure.

Independent Estimate | Annual Benefit of Faster Detection Against Monitoring Cost

With the inputs assembled, we can calculate the annual effect.

There are 14 incidents a year and the detection time saved per incident is 2.25 hours, so the total time saved in a year is 14 multiplied by 2.25, or 31.5 hours. Multiplying those 31.5 hours by the undetected cost of 1,660 THB per hour gives an annual saving of 52,290 THB.

Against that sits the cost of introducing monitoring. Initial cost, covering the build of a monitoring server or cloud service, deployment of agents to each device, configuration of UPS network management cards, dashboard creation and notification route setup, comes to 180,000 THB. The monthly monitoring service fee, covering availability monitoring and alert delivery, is 28,000 THB per month, which is 28,000 multiplied by 12, or 336,000 THB a year.

Placing the two side by side gives the following.

Dividing the annual benefit of 52,290 THB by the annual service cost of 336,000 THB gives 15.6%. Before the initial cost of 180,000 THB even enters the calculation, the monthly fee alone is not covered.

We are presenting this result as it stands, deliberately. There are several ways to make the number look better. Raise the unit cost of undetected downtime, fold in the opportunity cost of stopped production, assume a higher incident count. Do any of that and the estimate becomes a tool of persuasion rather than material for a decision.

Read honestly, the estimate says one thing. Monetising the effect of shorter detection alone does not recover the cost of monitoring. Any decision about whether to introduce monitoring has to be built on that fact.

Faster Detection Alone Does Not Pay Back — Why We Do Not Monetise the Other Effect

Does that mean monitoring is not worth investing in? No, because an effect remains that we have not monetised. It is the effect of preventing escalation.

Small abnormalities, left alone, grow into large stoppages. Free disk space steadily declining stops nothing in itself, but the database stops the moment it reaches zero. A RAID array with 1 failed disk keeps operating, having merely lost its redundancy, but a second failure destroys everything. A degraded UPS battery is the same, doing nothing until the next voltage dip. A backup job failing repeatedly is worse still, since nobody is inconvenienced until an incident occurs, and by the time one does the situation is beyond recovery.

Performance monitoring and log monitoring catch exactly these states of not having stopped yet but heading in that direction. Catch them and act, and the large stoppage never happens at all. The loss from an incident that never happened is, naturally, never recorded anywhere.

Trying to monetise that effect always requires assumptions about probability. How many times a year would the disk have filled? What is the probability of the second RAID disk failing? Once every how many years does a situation arise where the backup is genuinely needed? None of those numbers can be set with any real basis. Setting them changes the order of magnitude of the estimate, but the new order of magnitude means nothing.

For that reason, this article does not monetise the escalation-prevention effect. That is not a statement that the effect is small. It is a statement that it cannot be estimated honestly. Monetising what cannot be monetised costs the whole investment case its credibility.

In practice we recommend presenting the two parts separately. One part is the effect of faster detection, which can be shown in money. In the model case that is 52,290 THB a year. The other part is presented without money, as a concrete list of the events you want to avoid. The database stopping so that a full day of results cannot be entered. A server failing while nobody has noticed that backups are not being taken. A rainy-season voltage dip that the UPS cannot ride through, taking the production management system down with it. In an internal approval process that list is usually what actually lands. A concrete enumeration of things you would hate to have happen carries more meaning for a decision maker than a figure of 15.6%.

Monitoring whether backups are actually being taken is one of the higher priority items in any monitoring design. For the design of backups themselves, see backup architecture and recovery thinking for business systems, which is worth reviewing while you draw up your list of monitoring targets.

Three Axes of Monitoring Design — What, How Far, To Whom

Let us restate the material so far in the language of design. Three things have to be decided.

The first axis is what to measure. Build a list of targets. Servers, network equipment, wireless access points, UPS units, and the services running on each server. The easy trap here is being satisfied with a list of devices. If the server is alive but the production management service on it has stopped, the user experiences it as down. Define what you measure in units of the functions users actually use, not in units of hardware. A definition such as “the production management system login screen returns a normal response” will catch a break anywhere along the path.

The second axis is how far counts as abnormal. This is threshold design. For availability monitoring, how many consecutive missed responses constitute an abnormality. For performance monitoring, what CPU utilisation sustained over what period is abnormal, and below what level of free disk space you raise a signal. These cannot be settled immediately after monitoring goes in. You have to measure normal values over a period and understand their spread before a meaningful line can be drawn. Setting loose thresholds at first and tightening once data has accumulated is the practical order.

The third axis is where the signal goes after detection. This is notification route design, the most neglected part and the one that fails most often. What has to be decided is the recipient during weekday working hours, the recipient at night and at weekends, and the secondary recipient when nobody responds. Add to that routing by severity. Sending every alert to everybody buries the important ones. A production management system stoppage should make a phone ring immediately, whereas a free disk space warning can wait until the next business day.

Monitoring does not function if any one of these three is missing. Deploy without deciding targets and things get missed. Deploy without deciding thresholds and alerts fire constantly. Deploy without deciding notification routes and detection triggers no action. All three, moreover, can be decided independently of whether monitoring is outsourced. That is what the earlier section meant by saying something has to be decided before the outsourcing question.

As for sequence, start from the first axis. Thresholds cannot be set until targets are fixed, and notification severity cannot be set until thresholds are fixed. Conversely, once the targets are fixed, the rest becomes a matter of filling in each target in turn.

Typical Ways Threshold Design Fails

Threshold design is the point at which monitoring projects most often fail in substance. Here are the failures we see most.

Setting thresholds far too tight from day one. Configure an alert whenever CPU utilisation exceeds a high level and, from the first day, alerts fire every night while the batch window runs. When alerts keep firing on normal behaviour, staff learn within days to ignore the notifications, and once ignoring becomes a habit, a genuine abnormality passes unnoticed. Monitoring in place and yet unable to detect anything is the worst outcome available.

Settling on thresholds that are far too loose. This is the rebound from the above, where thresholds are relaxed until alerts stop firing. Notify only when free disk space falls below the last percentage point and things certainly go quiet, but by the time the notification arrives there is no time left to act. The purpose of a threshold is to tell you while you can still do something, not to tell you that the limit has been reached.

Setting thresholds without collecting normal-state data. This is the pattern of adopting general recommended values as they are. Load profiles differ by plant. Some are flat out during the day, others are heaviest during the overnight batch. A line drawn without knowing your own normal state is a line without a basis. Devote an initial period to data collection and fix thresholds only after you have seen the actual range of variation.

Not separating alerts by severity. When every notification arrives through the same channel in the same format, the recipient cannot triage. Requires immediate action, check the same day, review weekly in aggregate. Splitting into roughly those three levels alone changes the practical effectiveness of notifications dramatically.

Never revisiting a threshold once set. As equipment, users and data volumes grow, normal values move. Keep using the thresholds set at deployment and within a few years they no longer match reality. Set aside time roughly once a year to check thresholds against recent measured values.

What these failures share is treating a threshold as a technical setting. In reality a threshold is an operational rule about who acts and when. Placing tight thresholds where there is no capacity to respond only piles up alerts. Set thresholds to match the number of people available to respond and the hours they are available.

Monitoring Logs and the PDPA — Retention Periods and Access Rights

Introducing monitoring accumulates logs as a by-product. Who logged in and when, which terminal accessed which system, which operation produced an error. These are useful for incident response, but they need careful handling.

Thailand’s Personal Data Protection Act came into full force on 1 June 2022. According to the explanation from KPMG, covered businesses have an obligation to maintain records of personal data processing, and where processing carries higher risk there is also an obligation to appoint a data protection officer. Processing of data related to the monitoring of a data subject’s behaviour is treated as potentially falling within scope.

The point to avoid misreading is that this does not mean monitoring logs are necessarily personal data. Server response times and CPU utilisation have no link to an individual. Access logs containing user IDs, on the other hand, may well link to identifiable individuals. Whether they do depends on the content of the logs, and there is no uniform answer. The actual judgement should be made by listing the log fields you collect and confirming with a specialist.

The penalty levels are not trivial. The commentary from One Asia Lawyers indicates administrative fines of up to 5,000,000 THB and criminal fines of up to 1,000,000 THB for violations. Monitoring projects tend to advance on IT considerations alone, but everyone involved needs to share an understanding that log handling is also a legal question.

Three things should be settled as a minimum. The first is the retention period. Decide what the logs are retained for, set a period appropriate to that purpose, and delete anything past it. Retaining indefinitely just in case is the most dangerous setting available, in the sense that no purpose has been defined. The second is access rights. State explicitly who can reach the monitoring dashboard and restrict viewing of any screen containing information that identifies individuals. The third is a review of what is collected. Check both at deployment and at periodic reviews whether you are collecting fields that incident response does not need. What is never collected never has to be managed.

Deciding these three during the design stage avoids extra work later. Try instead to sort out log handling after the system is running and you add the awkward problem of what to do with data already accumulated.

How To Roll It Out | Four Steps

Finally, here is the sequence for actually introducing monitoring.

Step one is an inventory of targets. List every server, network device, wireless access point and UPS in the plant. Doing this exercise in practice turns up equipment nobody knew existed at most factories. A switch added during an expansion, a server left in place from an earlier project, a wireless access point installed privately by a staff member. Before deciding what to monitor, establish what exists. Time spent here is amply repaid.

Step two is definition in units of functions as users see them. Once the device list exists, translate it into the user’s perspective. The production management system is usable, the shared folder on the file server opens, wireless connectivity works. Define in writing what normal means at that level. Proceed to configuration with a vague definition and you will not be able to detect the state where every device is green but users cannot work.

Step three is deploying availability monitoring and power monitoring. Only now do you touch the equipment. The priorities are availability monitoring and monitoring of the UPS and power side. As the model case showed, roughly 57% of incidents originate on the power side, so deploying availability monitoring alone without watching power leaves the unexplained restarts happening. If your UPS has no network management card, add it at this stage. Performance monitoring and log monitoring can come afterwards.

Step four is fixing thresholds and notification routes. Collect data for a period after step three and draw thresholds once the normal range of variation is visible. At the same time, decide the notification routes for weekday working hours, for nights and weekends, and for the secondary contact, and configure routing by severity. Then, without fail, trigger a deliberate test abnormality and confirm that notifications arrive. Cases of a notification route being configured and left in operation while it does not actually deliver are surprisingly common.

Of the four steps, one and two are design and three and four are build and operation. Results appear only once you reach the fourth. A plant stopped at step three, with monitoring tools installed but alerts reaching nobody, has spent the investment without collecting the benefit. When planning the rollout, treat all four steps as a single project.

Frequently Asked Questions

Where should factory system monitoring start?

Start with availability monitoring and power-side monitoring. Availability monitoring is the simplest to configure and catches complete stoppage, the incident type with the largest loss. Power deserves priority as a condition specific to factories in Thailand. In the model case, 8 of the 14 annual incidents, roughly 57%, originated in power quality. Performance and log monitoring are valuable, but their thresholds need normal-state data, so the practical order is to deploy availability monitoring first and prepare while data accumulates. Note also that the inventory of monitoring targets and the definition of what normal means should be completed before any tool is selected.

How much faster does monitoring find incidents?

In the model case estimate, an average of 2.4 hours under reliance on user reports fell to an average of 9 minutes, or 0.15 hours, with availability monitoring and threshold alerts. That is 2.25 hours saved per incident, a reduction of approximately 94%. However, monitoring shortens only the time to detection, not the time from detection to recovery. And unless a recipient is defined for notifications at night and at weekends, faster detection does not bring forward the start of the response. Realising the benefit requires deploying the notification route design along with everything else.

Can the cost of monitoring be recovered through faster detection alone?

Not in the model case. Annual detection time saved is 14 incidents multiplied by 2.25 hours, or 31.5 hours, and multiplying by the undetected cost of 1,660 THB per hour gives an annual benefit of 52,290 THB. Against that, the annual monitoring service cost is 28,000 THB per month over 12 months, or 336,000 THB, plus an initial cost of 180,000 THB. Dividing the benefit by the annual service cost leaves 15.6%. The value of monitoring lies rather in stopping small abnormalities before they grow into large outages, but because that effect depends on assumptions about probability, we deliberately do not monetise it in this article.

Does having a UPS prevent power-related incidents?

Having a UPS and riding through a dip are two different things. Thai ambient conditions accelerate the ageing of UPS batteries, which in general degrade within roughly 1 year, so an annual inspection and replacement check is the accepted guideline. A degraded battery shows no sign at all under normal conditions, and the shortfall in capacity appears only when a dip actually arrives and the unit transfers to battery. What matters, therefore, is not whether a UPS is installed but whether battery health and transfer counts are included in what you monitor. A UPS with no network management card fitted holds the information but cannot pass it outward.

Are there PDPA considerations in retaining monitoring logs?

Thailand’s PDPA came into full force on 1 June 2022, and processing of data related to the monitoring of a data subject’s behaviour is treated as potentially within scope. That said, it cannot be asserted that monitoring logs are necessarily personal data. CPU utilisation and response times have no link to individuals, whereas access logs containing user IDs may. In practice, decide three things at deployment: set retention periods from the purpose and delete afterwards, restrict dashboard access rights, and stop collecting fields that incident response does not need. Individual judgements should be confirmed with a specialist.

Summary

To bring the points together.

What determines the loss from a factory IT incident is not the cause but the time to awareness. Recovery work is bounded by technical constraints, but detection time can be compressed structurally. As long as you depend on user reports, stoppages at night and at weekends cannot be detected at all.

System monitoring splits into availability, performance and logs, each catching a different stage. And factories in Thailand have a fourth layer independent of those three, power quality. Voltage dips cannot be caught by availability monitoring, and unless UPS battery health is being watched, the presence of a UPS guarantees nothing about tolerance to dips.

In the model case estimate, a metal parts machining plant in Ayutthaya Province experienced 14 incidents in a year, of which 8, roughly 57%, originated in power quality. By season the split was 9 in the rainy season and 5 in the dry season, a skew that comes almost entirely from the power side. Detection averaged 2.4 hours, and with availability monitoring and threshold alerts it falls to an average of 9 minutes, or 0.15 hours, saving 2.25 hours per incident, a reduction of approximately 94%. Annual time saved is 31.5 hours, which multiplied by the undetected cost of 1,660 THB per hour gives an annual benefit of 52,290 THB.

Against that, monitoring costs 180,000 THB initially and 28,000 THB monthly, or 336,000 THB a year. Dividing the benefit by the annual service cost leaves 15.6%, so faster detection alone does not pay back the investment. It would be possible to dress that number up, but doing so would stop it being material for a decision, so we present it as it is. The real value of monitoring lies in stopping small abnormalities before they grow into large outages. Because that effect depends on assumptions about probability, we do not monetise it here. These are independent estimates rather than the figures of a real company, so please look at the reasoning — how the build-up is assembled and how far it is legitimate to call something an effect — rather than at the amounts themselves.

Three things have to be decided in the design. What to measure, how far counts as abnormal, and where the signal goes after detection. All three can be settled independently of whether monitoring is outsourced. Debating delegation first goes nowhere precisely because these three remain open.

The rollout runs in four steps: inventory of targets, definition in units of functions as users see them, deployment of availability and power monitoring, and fixing of thresholds and notification routes. A state in which monitoring tools are installed but alerts reach nobody is a state of having spent the investment without collecting the benefit. Finally, always trigger a deliberate abnormality and confirm the notification arrives.

As a first move, write out how many incidents your own site had over the past year and how many hours each went unnoticed. Once the counts and the hours sit side by side, you already have half the material needed to judge whether monitoring deserves investment.

It is perfectly fine to be at the stage where what should be monitored has not been decided. TOMAS TECH designs and operates IT infrastructure for Japanese-owned factories in Thailand, and we are happy to start from taking inventory of monitoring targets and defining together what normal means for your systems. Consultation is welcome even with no implementation assumed, so if you would like to turn your own incidents into numbers, please get in touch through our contact page.

References

• JETRO — Talent shortages and responses in Thailand, with attention on future minimum wage trends, survey of IT talent shortages at Japanese-affiliated companies, in Japanese
• ASPIC — Comparison of 12 MSP services, what they cover and what they offer, tier structure of outsourced monitoring services, in Japanese
• OutageCost.com — Cost of IT Downtime, downtime loss research covering large enterprises
• Biz Info Log — Caution even in urban Bangkok, momentary voltage dips outnumber blackouts in Thailand, frequency of voltage dips in Thailand, in Japanese
• Thai Jiyu Land — PC Support Thailand column number 254 on countermeasures for power failures, rainy season outages and UPS battery ageing, in Japanese
• KPMG — Support for compliance with the Thai Personal Data Protection Act PDPA, PDPA obligations and DPO appointment, in Japanese
• One Asia Lawyers — Enforcement cases under the Personal Data Protection Act PDPA in Thailand, PDPA penalties and enforcement, in Japanese