// Downtime tracking
Custom downtime tracking software that uses your reason codes and planned vs unplanned rules
We build custom downtime tracking software for plants that need better production data. Operators record each stop with a cause and a duration, your admins control the reason codes, your rules decide what counts as planned, and every event lands in SQL Server for Tableau. Your first call is with an engineer.
// Sound familiar?
You can’t fix production downtime you can’t see
“We need better production data and visibility into downtime.” If your team has said that, one of these is probably why. To see what those stops cost you first, run your numbers through the downtime cost calculator.
“Stops go on a clipboard and get typed up days later.”
By then the times are rounded and the short stops are gone. The summary shows a tidier shift than the one that happened.
What to record for every stop →“Half our reasons just say ‘Other’ or ‘machine down’.”
Free-text reasons can’t be counted, so nobody can rank causes or tell whether a fix worked.
Design a reason code list →“Every line keeps its own spreadsheet.”
Different columns, different codes, different ideas of what counts as a stop. Merging them for the weekly meeting eats an afternoon, and the totals still don’t agree.
Signs you’ve outgrown it →“A changeover that ran long still counts as planned.”
Without a clear line between planned and unplanned downtime, overruns hide inside the plan and OEE looks better than the floor feels.
Draw the line consistently →// Buy or build
Packaged OEE products or custom downtime tracking software?
Packaged OEE tools and production downtime tracking software fit some plants well. Some include sensors that detect stops automatically and dashboards that work on day one. If their reason lists and reports match how you run, buying may be faster, and the engineer on your first call will say so.
A custom build makes sense when the software has to follow your process:
- Your reason codes and categories, managed by your admins
- Your planned vs unplanned rules, applied the same way every shift
- Screens built around your lines and the devices operators already use
- Downtime events in SQL Server, structured for the reports you already run
Weighing a full MES instead?
If downtime is one piece of a bigger plant-system decision, our guide covers when packaged software wins, when a custom app makes sense, and the hybrid in between.
Read the build vs buy MES guide →// Capture
Manual, automatic or hybrid downtime capture
Machine signals are good at recording when a stop happened. People are good at recording why. Downtime tracking software for small manufacturers doesn’t have to start with sensors on every machine. Our guide on how to track production downtime compares the options in full.
Manual
Operator entry
Operators record each stop with its cause and duration at the line. It captures the reason well. The risk with any manual log is timing: short stops get skipped and durations get rounded, so entry has to take seconds.
Automatic
Machine signals
For machine downtime tracking, a run/stop signal from the equipment gives exact start and end times and catches short stops nobody would write down. It can’t say why the machine stopped.
Hybrid
Signal plus reason
The machine marks the stop and the operator picks the reason. A practical path: start with operator entry on one line, then add signals where exact timing matters most.
// Reason codes
Downtime causes, durations and admin-controlled reason codes
Each stop gets a duration from its start and end times, not a number typed in at the end of the shift, and a cause from a short two-level list: a category such as Equipment, Material or Changeover, then a specific reason.
Your admins manage that list, not developers. They can add, rename or retire a reason, or require a note whenever someone picks Other. Past events keep the codes they were logged with, so last year’s reports still add up.
Our downtime reason codes guide has starter lists for planned and unplanned stops.
// Planned vs unplanned
Planned and unplanned stops, classified the same way every shift
Planned downtime is a stop scheduled before the shift started: preventive maintenance, a changeover on the schedule, a planned clean. Unplanned downtime is everything else. The hard cases sit in between, like a scheduled changeover that runs an hour over.
When operators decide case by case, an overrun is easy to file as planned, and if planned stops are left out of your availability figure, availability and OEE look better than they are. A custom tracker applies your rules instead: each reason carries a default class, and time past a stop’s scheduled length can be split off as unplanned automatically.
Our guide to planned vs unplanned downtime has a decision table for the gray areas.
// Reporting
Report-ready downtime data in SQL Server and Tableau
A downtime report is only as good as the rows underneath it. We store each stop as one structured event in SQL Server, and Tableau reads clean reporting views instead of a weekly spreadsheet export. Codes are saved as IDs from the admin list, not typed text, so “Jam” and “jammed” never split one cause into two bars on a Pareto chart.
Designing the tables yourself? Our downtime database schema guide lays out runs, stop events, reason codes, shifts and reporting views. Food and beverage teams should also read OEE for food and beverage lines, which covers changeovers, sanitation and allergen cleans.
- One row per stop, with start and end times
- Line, machine and shift on every event
- Reason codes stored as IDs from the admin list
- Planned or unplanned set by rule, not memory
- Reporting views Tableau connects to directly
// How it runs
How downtime tracking app development works
Step 1
Walk through how stops get recorded today
An engineer talks with the people who log stops, run the line and build the reports, and collects your current codes, your planned vs unplanned rules (written or not) and the reports you wish you had.
Step 2
Agree on the event record and code list
Before any screens, we settle what one downtime event holds, the reason list and the classification rules, so the database answers the questions you’ll ask of it.
Step 3
Try the entry screens on one line
Operators use the screens on a real shift. Anything that slows them down gets changed before the app goes to more lines.
Step 4
Roll out, connect reporting, keep it running
Add lines, point Tableau at the reporting views and hand the code list to your admins. The same crew that built it hosts and maintains it.
// Client work
Chelten House: a plant-floor app that records downtime causes and durations
Chelten House Products is a fourth-generation food manufacturer of sauces, dressings and condiments. We built them a custom manufacturing data-management application with administrative controls, where operators record production performance, product traceability and equipment downtime.
Read the Chelten House case study, see what else we build on our manufacturing software and food manufacturing software pages, or browse all services.
Manufacturing · Data collection
Production, traceability and downtime data from the plant floor
A custom application where Chelten House operators record production performance, product traceability and equipment downtime (planned vs unplanned, with causes and durations), stored in SQL Server to support their Tableau reporting.
// Credentials
The basics, before you ask.
Since 2018
Building and supporting software
Orlando, FL
100% U.S.-based team, clients nationwide
SAP Ariba
Registered supplier
NDAs welcome
Happy to sign before you share details
Top Web Design Companies
DesignRush
// FAQ
Downtime tracking software FAQ
Do we need sensors on our machines?
Not to start. Operators can record stops with their causes and durations, which is how the Chelten House app captures downtime. Machine signals can add exact timing, but the reason for a stop still comes from people.
Can it use our existing reason codes?
Yes. In a custom build your reason codes and categories are managed by admins, so the list matches how your plant talks about stops.
Can the data feed our reporting?
Yes. Data stored in SQL Server can feed reporting tools such as Tableau. Chelten House’s app, for example, stores its data in SQL Server, which supports their Tableau reporting.
Should changeovers count as planned or unplanned downtime?
It depends on whether the changeover was scheduled and how long it was planned to take. Our guide to planned vs unplanned downtime covers the gray areas.
When does a downtime spreadsheet stop being enough?
When several people edit it, lines use different codes, you need history you can query, or someone has to control the code list. Paste your current log into our free downtime Pareto analyzer to see what it already tells you.
Who supports it after launch?
The same crew that builds it hosts and maintains it, so changes come from people who already know your rules and your data. See maintenance and support.
// Keep exploring
More on tracking and reducing downtime
Free tool
Downtime Pareto analyzer
Paste your downtime log and get a Pareto chart of causes, a planned vs unplanned split and data-quality flags. Free, in your browser, nothing uploaded.
Use the free tool →Guide
Track production downtime
How to track production downtime: what to record for every stop, who records it, manual vs automatic tracking, and how to turn the log into weekly decisions.
Read more →Service
Replace Excel
Replace Excel with custom software: a secure web app and database with real permissions, an audit trail, phone access and your spreadsheet data imported.
Read more →// Bring us in
Tell us about the software your business runs on.
A new build, a system that’s hard to use, a stuck project or a prototype that needs to go live. An engineer, not a salesperson, will get back to you.
202-88-MAGIC · or email info@effortlesspresence.com