Tracking machine downtime in ERPNext

Tracking machine downtime in ERPNext: when shop floor stoppages need a system of record

A plant supervisor or maintenance lead often learns why a machine stopped from a paper log, a shift handover or a verbal report at the end of the day, which makes it hard to see which workstation loses the most hours or whether the same fault keeps returning. ERPNext records each stoppage as a Downtime Entry against a workstation and reports the results in the Downtime Analysis report, which sits among the manufacturing reports. Teams usually need this when stoppage reasons are being argued rather than counted, when maintenance requests cannot be tied to actual production loss, or when management asks for downtime figures that nobody can reproduce from the floor.

The feature covers three things: recording stoppages, analysing them by workstation, and linking the results to maintenance planning. The last link is the one to design deliberately. The Downtime Analysis report is only as useful as the workstation master behind it, so the workstations, their names and their working hours should be modelled first, ideally as part of the routings and capacity work described elsewhere on this page. Before go-live, confirm with your ERPNext version which stoppage reasons and fields your operators will be asked to select, who is allowed to create and edit Downtime Entries, and whether operators can enter them from the shop floor or only supervisors can.

The documentation supports the recording and the report. It does not, on its own, define how downtime turns into a maintenance plan. Whether a repeated stoppage opens a maintenance task, a preventive maintenance schedule is adjusted, or spare parts are reordered is a process decision that your team must map and confirm, including which tools hold maintenance records if they live outside ERPNext. Ask the implementation partner to show, on your own workstation data, how the report groups stoppages and how a supervisor would act on the top items each week.

Which downtime recording approach fits your shop floor

This table compares three ways to capture machine stoppages in ERPNext: shift-end manual entries, entries logged at the time of stoppage, and entries derived from machine signals. Read each row against your shift pattern and how quickly maintenance needs to see a stoppage. The main takeaway is that faster capture usually adds build work, so match the approach to the decisions the downtime data must support.

Factor	Shift-end Downtime Entries	Logged at stoppage (shared terminal or tablet)	Derived from machine signals
Who enters data	Supervisor, from memory and logs, at shift end	Operator or line lead, at the workstation when the machine stops	No person enters data; the integration writes the stoppage records
Time to reach the report	End of shift, so same-day analysis is limited	Near real time, once the entry is saved	Near real time, depending on the signal feed and integration schedule
Data quality risk	High: start and end times are estimated and short stoppages may be missed	Medium: accurate timing, but operators may pick the wrong reason code under pressure	Lower for timing, but signals alone do not explain cause, so reason codes still need a person
Extra build work	Low: standard Downtime Entry setup and reason code list	Moderate: terminal layout, access rules and training for operators	High: machine connectivity, signal mapping, data validation and ongoing maintenance of the integration
Link to maintenance planning	Useful for trends, weak for responding to individual failures	Good for recurring failures when reason codes are consistent	Strongest for failure patterns, if signals and reason codes are reliable
What to confirm in your version	Available Downtime Entry fields, stop reason types and whether reports filter by workstation	Whether the shared view can be restricted to the required fields and how user access is set	Which machine data sources are supported, and how any custom mapping is built and tested

Setting up Downtime Entries and workstations step by step

This sequence gets a working downtime capture process in place, from a confirmed ERPNext setup and workstation list to tested stoppage records that reconcile with the machine log. Each step closes with a check the team can run before operators use the process on the shop floor.

Confirm version and manufacturing module status
The ERPNext administrator confirms which major version is running on the site, checks that it sits on a version listed as supported in Frappe's support policy, and verifies that the Manufacturing module is enabled for the company. Downtime Entries and the Downtime Analysis report depend on Manufacturing being active, so this step comes first. Check the installed version on the site's About page and confirm the Manufacturing workspace appears in the Desk. The step is complete when both checks pass on the production-like test site, and the reader has recorded the version number for the project file.
Define workstations for each machine or cell
Manufacturing or production engineering creates one Workstation record for each machine, or for each cell where several machines share one stoppage process. Record the name, working hours and hourly cost fields the business uses, and keep names consistent with the asset tags on the floor so operators can match a screen entry to a physical machine. Decide early whether a single machine with two spindles needs two workstations, because downtime is recorded against the workstation. The check is a list of workstations that matches the machine register line by line, with no duplicates and no machine missing.
Agree the stoppage reason list
Operations and maintenance agree a short, controlled list of stoppage reasons, such as breakdown, changeover, material shortage, quality hold and planned maintenance, and decide who may add new reasons. The list should map to the categories the Downtime Analysis report will be read against, so that reports can be compared across shifts and months. Record the agreed list in a controlled document and load the matching values into ERPNext as the reason options in the Downtime Entry form. The check is a signed-off list that both operations and maintenance have reviewed, with a named owner for changes.
Configure roles for operators
The ERPNext administrator creates or assigns a role for shop floor operators that allows creating and submitting Downtime Entries and reading the related Workstation records, without granting write access to Work Orders, Job Cards, Stock Entries or Workstation master data. Field-level and document-level restrictions should be tested with a sample operator account, because the default permissions for a broad manufacturing role may be wider than the process needs. Confirm exact permission settings in the ERPNext role permission manager for your version. The check is an operator test account that can create a Downtime Entry and is refused when it tries to edit a Work Order or Workstation.
Enter test stoppages on a test site
A named floor supervisor and an operator enter a set of illustrative stoppages on a non-production site, covering each reason on the list, a stoppage that spans a shift change, and a stoppage that is corrected after entry. The test should use the same workstations and the same recording routine that will be used on the floor, including how start and end times are captured. Record every test entry in a simple test log with the expected duration, so the results can be compared later. The check is that each test entry saves with the correct workstation, reason and times, and that the corrected entry is traceable.
Reconcile totals with the Downtime Analysis report
The reporting owner runs the Downtime Analysis report in the manufacturing reports for the same period as the test log and compares the totals by workstation and by reason with the paper sheet or machine log. Any difference is traced back to a specific entry, whether a missed stoppage, a wrong workstation or a time-zone or rounding issue. Differences are resolved before go-live, and the agreed reconciliation method is written down for the monthly close. The check is a report total that matches the reference log for every workstation in the test period, or a documented explanation for each remaining difference.

Reading the Downtime Analysis report by workstation, shift and audience

Supervisors use the Downtime Analysis report to see which workstations stop most often and during which shifts those stoppages cluster. The report groups recorded Downtime Entries by workstation, so the first question is which machines appear at the top of the list for the period you selected. The second is whether the same workstation loses time on one shift more than others, which often points to staffing, changeover practice or handover gaps rather than the machine itself.

Start with the filters: Confirm the date range, company and workstation filters before comparing anything. A report that excludes a shift or a plant will look cleaner than it is.
Compare stoppage counts with total duration: A workstation with many short stops and one with a few long stops need different responses. Check which measure the report sorts by.
Look at shift patterns over several weeks: A single bad night shift can reflect one material batch or one absent operator. Repeated clustering on the same shift is the signal worth acting on.
Note what the report does not show: It does not show why a machine stopped, who was present or whether the line was running at planned speed. Those details live in the individual Downtime Entries and in shop floor notes.
Avoid single-period conclusions: Compare at least several comparable periods, and account for planned stops, holidays and product changes before calling a workstation unreliable.

Before acting, confirm the report's filters and columns in your ERPNext version against the Downtime Analysis documentation.

Linking downtime results to maintenance planning

Downtime data is only useful to maintenance if it changes a decision. Group the stoppage reasons recorded in Downtime Entries by workstation and look for repetition: the same reason recurring on one machine points to a failure mode, while scattered one-off reasons usually point to operator or process causes. Compare each cluster with the planned maintenance and inspection calendar for that workstation. If a machine stops every few weeks for the same fault and its preventive tasks are not addressing that fault, the schedule is the problem. Failures that recur despite planned work need root cause analysis, and failures with long repair times or parts that are hard to source need a spare parts decision, such as stocking the component or agreeing a supplier lead time.

ERPNext holds the stoppage record, but the maintenance schedule often lives in another system, such as a CMMS, a spreadsheet or a calendar owned by the maintenance team. Before building anything, confirm where each maintenance task, its owner and its due date are recorded, and agree which system is the source of truth for each. The connection can be a documented monthly review, where the Downtime Analysis report is exported and reviewed alongside the schedule, or an automated link that creates maintenance records from downtime thresholds. Either option needs scoping: a review needs a named owner and a fixed agenda, while an automated link needs field mapping, duplicate handling and an agreed rule for when a stoppage becomes a work request.

The trade-off is between a simple review cadence and an automated link. A review is cheap to set up, easy to correct when the reason codes are poor, and keeps people in the decision, but it reacts only as fast as the meeting. An automated link responds quickly and leaves an audit trail, yet it turns the quality of downtime reason codes into a control: a poorly chosen reason creates the wrong work order. Many teams start with a review for one or two quarters, then automate only the rules that proved stable. Ask any partner to quote the review first, and to list the integration, mapping and testing effort separately if an automated link is in the scope.

Security and data integrity for shop floor stoppage records

Downtime records feed maintenance decisions and OEE discussions, so their integrity matters as much as their completeness. The cards below cover who can write them, how corrections are kept honest, how shared terminals are handled, how the data is protected, and where ERPNext must stop short of control networks.

Role permissions for entries

Decide which roles can create, submit and amend Downtime Entries, and keep that list short. Operators may need to log stoppages while supervisors and planners review them. Check that read access to the records is separate from write access, and test the permission set with a non-administrator account before go-live. Confirm this against the role and permission settings in your own ERPNext version.

Audit trail and late corrections

Entries logged after the event are common, and they should be visible as corrections rather than silent overwrites. Agree a rule for who may amend a stoppage, how a reason is changed, and whether the original values remain visible. Ask the implementer to show the version history for an edited record during acceptance testing.

Report access by plant or company

Downtime reports often show machine names, output loss and maintenance notes that plant managers should see only for their own sites. In a multi-company setup, confirm that user permissions restrict workstations and reports to the right company. Test with users from two plants to check that neither sees the other's data.

Operator logins on shared terminals

A terminal left logged in lets one person record stoppages under another name, which weakens accountability. Decide whether operators log in individually, use short session timeouts, or use a terminal role with limited rights. Confirm how your identity setup, such as LDAP or social login, handles session length and logout on the shop floor.

Backup and recovery of records

Downtime data lives in the same database as the rest of ERPNext, so backups must cover it and restores must be tested. Ask who owns backup schedules, where copies are stored, and how long a restore takes in your environment. Document the recovery point you can accept for stoppage records, and rehearse a restore to a separate site before relying on it.

Boundary with OT networks

The ISA/IEC 62443 series and NIST SP 800-82 Rev. 3 are the standard references for securing industrial control environments, covering asset owner programs, system design and the zones that separate control networks from business systems. ERPNext is an IT system and should not sit inside a control network. Machine status should move to ERPNext through a controlled, one-way or brokered path that your OT security team has approved.

Where ERPNext ends and industrial control systems begin

A Downtime Entry in ERPNext is an IT record of when a workstation stopped and why. It is not a control function. The stoppage itself, the PLC that halted the line, the SCADA alarm and the safety interlock all sit in operational technology (OT) that ERPNext does not run. Keep that boundary explicit in the design document. Decide who may create, edit and submit Downtime Entries, and confirm that nobody treats an ERPNext record as the trigger for a machine action. Manual entry by operators is the lowest-risk pattern because a person sits between the shop floor and the record.

The risk profile changes once PLCs, SCADA or DCS feed ERPNext automatically. A network path from the control zone to the ERP network, an API user or a middleware job that writes status into ERPNext each becomes a route into systems that control physical equipment. The ISA/IEC 62443 series treats this as a zone and conduit question, so ask your OT engineers to document which zones exist, which conduits cross them and who owns each one. Confirm with your OT security lead whether the ISA/IEC 62443 approach is already used at your sites. Data should flow outward from the control network through a one-way or tightly restricted interface, not as inbound commands.

Whether NIS2 applies depends on your sector, size and member state, and the NIS2 manufacturing sector in Annex II covers several NACE Rev. 2 divisions, so do not assume an answer from the topic. If you are in scope as an important or essential entity, significant incidents follow the 24-hour early warning, 72-hour notification and one-month final report timeline in Article 23. Machinery placed on the EU market has its own requirement: the Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and includes an essential requirement that connecting another or remote device must not lead to a hazardous situation. Ask counsel and the relevant competent authority to confirm both obligations for your organization before you connect any machine to ERPNext.

Limits to confirm in your environment before you rely on downtime data

Downtime figures only support maintenance planning if the workstation setup, timestamps and report logic match how your plant actually stops. The cards below cover the checks to run on your own version and your own test data, because the feature set, data entry model and report behavior should be confirmed rather than assumed.

Feature availability by version

Confirm that the Downtime Entry doctype and the Downtime Analysis report exist in the ERPNext version you run or plan to run, and that they behave the same on your deployment. The Downtime Analysis report is documented in the manufacturing reports, but the exact screens and fields can differ between major versions. Check the vendor documentation for your version, then test on a copy of your site before go-live.

Workstation and reason code mapping

Each Downtime Entry points to a workstation, so every machine that can stop must exist as a workstation with a clear owner and naming rule. Decide how you will group stoppage reasons, such as breakdown, changeover, material shortage or no operator, and whether those reasons are free text or a controlled list. Walk through one line from the floor to the report and confirm each machine appears exactly once.

Entered or captured timestamps

Find out whether a Downtime Entry is typed by a supervisor after the fact or captured from a PLC, historian or machine signal. Manual entry carries rounding and recall errors, while captured data depends on an integration you must build and validate. Ask the vendor how start and end times are stored and time zone handling works across sites, and measure the gap between recorded and actual stops on a sample day.

Stoppages across shifts and days

A stoppage that starts on the night shift and ends the next morning must be recorded in a way that the report attributes correctly to each shift and day. Check whether one entry can span a shift boundary or midnight, or whether you must split it, and how the report allocates duration in each case. Test a multi-day breakdown and compare its total against the logbook.

Partial and overlapping stoppages

Some events stop one station while another keeps running, or a line slows without fully stopping. Confirm whether the model can represent a partial stoppage, and what happens when two entries overlap on the same workstation. Double counting inflates availability losses and misdirects maintenance budgets, so run overlapping test records and check the totals before you trust the figures.

Performance and data volume

A large plant can produce many stoppage records per day across many workstations, and reports that scan wide date ranges can slow down. Ask for a load test using your expected volume, then review the report runtime, background job behavior and database growth on a staging system. Plan how long downtime history is kept and whether older records move to an archive.

What downtime tracking costs and what it asks of your team

How much effort does a downtime tracking setup take?

The effort scales with how many workstations you track, how much agreement you need on the reason list, and how many roles touch the data. Each workstation needs a correct record, each stoppage reason needs a clear definition that operators will select the same way on every shift, and each role that enters or reviews downtime needs permissions set and tested. Testing on live shifts and training the supervisors and operators who log events are often the largest share of the work, because a setup that is technically correct still fails if people record stoppages inconsistently. Ask any quote to list these drivers separately so you can see where the effort sits.

Can our team set up downtime tracking without a partner?

A basic setup can usually be done in-house if your team already has ERPNext manufacturing experience and understands how workstations, Downtime Entries and the Downtime Analysis report fit together. The questions that push a project toward a partner are the number of integrations, such as pulling stoppage signals from machine controllers or a SCADA layer, custom reports, and changes to roles or approval steps. Those items add design, testing and security review work, so the question is less whether you can configure ERPNext and more whether your team has capacity and skills for the integration and validation work around it.

How long does downtime tracking take to put into production?

The duration depends on the scope you agree and on how long approvals take, not on a fixed period for every plant. A workstation-only setup with a reason list you already use moves faster than one that needs sign-off from quality, maintenance and operations, or that waits on network access to shop floor equipment. Test shifts also add time, since you should run the process on real production before relying on the reports. DeployOpen agrees timelines in the written scope before work starts, so ask for the timeline as part of that scope rather than relying on a general estimate.

What does the work need from our team before we start?

Four inputs make the build faster and reduce rework. First, a complete machine list with the workstation names as they should appear in ERPNext. Second, an agreed set of reason codes with a plain definition for each, including which ones count as planned stops and which as breakdowns. Third, a named maintenance owner who decides how downtime feeds into planning and who signs off the reason list. Fourth, time for test shifts, when operators and supervisors enter real stoppages and the team checks the records and the report against what happened on the floor.

What recurring work follows go-live for downtime tracking?

Downtime tracking is not a one-time build. The reason list needs upkeep as processes, machines and products change, and a new reason added without a definition quickly makes the reports inconsistent. Someone should review the Downtime Analysis report on a regular cadence and check that entries are complete. Access changes need handling when people move roles or leave, and ERPNext upgrades need testing against your custom reports and workstation setup. Plan an owner and a review routine for these tasks, because they recur for as long as the process runs.

Is machine data integration included in the downtime tracking setup?

Machine data integration is a separate scoped item, not part of a standard Downtime Entry setup. Entries made by operators on the ERPNext side need no machine connection. Automatic capture from controllers, PLCs or monitoring systems requires a decision on the data source, network path, mapping to workstations, and security review of how shop floor systems connect to ERPNext. Those decisions belong in a written scope with their own deliverables and timeline. Ask whether a quote covers manual entry only or includes any connection to machines, and what is needed from your OT and IT teams to support it.

What should we ask for in a downtime tracking quote?

Ask for a written scope that lists the workstations in and out of scope, the reason list and who approves it, the roles and permissions to be configured, the reports to be delivered, and the test shifts and training included. Ask which integrations are priced separately and what access they need. Confirm the timeline, the dependencies on your own staff, and what support is available after go-live, including whether upgrades and report changes are covered. A quote that cannot explain these items is hard to compare against an in-house plan.

How DeployOpen works on this

DeployOpen starts by agreeing in writing which machines, workstations and downtime reasons the ERPNext setup must capture and report on. We then configure, test and document the tracking workflow in your own infrastructure, so your team can run it and link the results to maintenance planning after go-live.

How we scope

Confirm which machines map to ERPNext workstations and how each one is named and grouped.
Agree the downtime reason codes, who may record stoppages, and when entries are required.
Define the maintenance planning outputs that downtime results must feed, in a fixed-scope written agreement.

How we build

Configure Downtime Entry settings, workstation records and reason lists in a test environment first.
Test the Downtime Analysis report by workstation against sample stoppages that your team reviews.
Document the entry procedure, report filters and maintenance hand-off steps for shop floor and planning users.

How we hand over

Deliver the configuration, test results and user guides as written deliverables with named owners.
Walk supervisors and maintenance planners through recording stoppages and reading the reports.
Confirm with your team which downtime fields and reports they will keep using before sign-off.

How we support

Offer ongoing support, upgrades and testing as a retainer after go-live, scoped separately.
Review reason codes and report changes when your production lines or ERPNext version change.
Confirm with us how version upgrades will be tested against your downtime configuration before rollout.

Tracking machine downtime in ERPNext