Publications

QlikSense Downtime Analysis: The MTTR That Is Costing You the Shift

September 10, 2026

Hector Pincheira

CIO | CTO
Digital Strategy & Technology Innovation

Ask your plant manager how long the line was down last month. He will give you a number. Then ask where that number came from, and that is where you really start your QlikSense downtime analysis: it almost always comes from a spreadsheet the supervisor fills in at the end of the shift, with events written down from memory and rounded to the nearest half hour. That record has a systematic, not at all random, bias. It only logs what hurt. The two-minute stops, the ones you fix by tapping the sensor and moving on, never make it to the spreadsheet. And in most plants they are between 15% and 30% of total downtime. The average manufacturing plant runs about 800 hours of unplanned downtime a year. The question is not whether your report is incomplete. It is by how much.

The bill almost nobody adds up

Before getting into QlikSense downtime analysis it is worth sizing the problem, because the cost of unplanned downtime has become hard to ignore. Aggregate estimates put it at around $260,000 an hour as an industry average. The differences by sector are enormous: automotive tops $2.3 million an hour, semiconductors goes past $100,000, and food and beverage runs around $30,000. The world’s 500 largest companies lose roughly $1.4 trillion a year to equipment downtime. That is 11% of their total revenue.

There is a more useful figure for a mid-sized Chilean company: every hour of downtime costs about 50% more today than it did in 2019. The reason is the tightened supply chain. When there is no buffer inventory, the stoppage is not absorbed: it propagates all the way to the customer.

💡 Key point: 82% of the companies that do measure their downtime report events averaging four hours, at an approximate cost of $2 million per incident. The ones that do not measure report much better figures. Obviously.

What is missing from your QlikSense downtime analysis: the events under five minutes

Here is the finding that throws most committees. A serious QlikSense downtime analysis starts by checking where the events come from, not with the expression. When a plant moves from manual logging to automatic capture from the PLC, measured availability drops between 12 and 18 percentage points. That is, it gets worse on paper. The plant is running exactly as before. What changed is that now you see all of it. Micro-stops (jams, sensor faults, brief operator interventions) are usually 1.5 to 2.5 times the volume of the stoppages logged manually.

A downtime dashboard fed only with events longer than 30 minutes is a dashboard that confirms what you already knew. It works for the monthly report and that is where it ends. The first dashboard of this kind I built, at a food plant, used calendar time in the denominator and returned 94% availability. So the shift crews, who knew perfectly well that number was not true, stopped looking at it within two weeks. Quite rightly.

QlikSense downtime analysis: from the raw event to the three indicators

A good downtime dashboard rests on three numbers and one ranking: MTBF (mean time between failures), MTTR (mean time to repair), availability, and a Pareto of causes. Everything else is decoration. And none of the three comes out right if the script has not prepared the ground first.

The script: where the events come from

// ============================================================
//  1. Rate table: a minute of downtime does NOT cost the same
//     depending on the cause. A missing input stops the whole
//     order; a scheduled cleaning costs nothing.
// ============================================================
MAP_CostoMinuto:
MAPPING LOAD * INLINE [
Causa, CostoMinuto
Falla mecanica, 1850
Falla electrica, 1850
Atasco / sensor, 1850
Cambio de formato, 900
Falta de insumo, 2100
Falta de operador, 1200
Limpieza programada, 0
Mantencion preventiva, 0
];
// What counts as planned. Maintenance defines this list,
// not IT. Getting it wrong invalidates the MTBF.
MAP_Planificada:
MAPPING LOAD * INLINE [
Causa, EsPlanificada
Limpieza programada, 1
Mantencion preventiva, 1
Cambio de formato, 1
];
// ============================================================
//  2. Downtime events from the SCADA history
// ============================================================
Paradas:
LOAD
    ParadaID,
    Linea,
    Estacion,
    Causa,
    Timestamp(InicioParada)                         as InicioParada,
    Date(Floor(InicioParada))                       as FechaParada,
    // Duration in minutes. RangeMax guards against the PLC
    // clock being out of sync: a stop never lasts -3 min.
    RangeMax((FinParada - InicioParada) * 24 * 60, 0)  as MinParada,
    // Planned vs. unplanned: the only split that really
    // matters for MTBF and availability.
    ApplyMap('MAP_Planificada', Causa, 0)              as EsPlanificada,
    // Micro-stop. Threshold at 5 minutes by convention,
    // adjustable per line. This flag is what uncovers
    // the gap against the manual report.
    If((FinParada - InicioParada) * 24 * 60 < 5, 1, 0) as EsMicroparada,
    // Cost of the event. Third argument = safety net:
    // a new cause does not arrive at zero cost, it arrives at 1500
    // and stays visible so Maintenance can price it.
    RangeMax((FinParada - InicioParada) * 24 * 60, 0)
      * ApplyMap('MAP_CostoMinuto', Causa, 1500)       as CostoParada
FROM [lib://SCADA/paradas_*.qvd] (qvd);
// ============================================================
//  3. Scheduled time. Without a denominator there is no
//     availability, and calendar time does NOT work:
//     a Sunday with no shift is not downtime.
// ============================================================
Turnos:
LOAD
    Linea,
    Date(Fecha)          as FechaParada,
    Turno,
    MinutosProgramados
FROM [lib://Maestros/turnos.qvd] (qvd);

Two things in this script deserve attention, because they are what holds up all the QlikSense downtime analysis that follows. The first is the flag EsMicroparada: on its own it changes no calculation. What it does is let you show the dashboard with and without micro-stops, and win the argument with evidence. The second one, on the other hand, is debatable: Cambio de formato was classified as planned, and in several plants setup runs out of control and should indeed penalize the indicator. That is a business decision, not a technical one, and it has to be written into the script so it can be revisited.

MTBF, MTTR and availability as master measures

// ---- MTTR: repair minutes per unplanned event ----
Sum( {< EsPlanificada = {0} >} MinParada )
/ RangeMax( Count( {< EsPlanificada = {0} >} DISTINCT ParadaID ), 1 )

// ---- MTBF: OPERATING time between failures ----
// The time denominator must be blind to cause selections.
// If the user filters "Falla mecanica" and scheduled time
// shrinks with it, MTBF shoots up and the dashboard
// lies in the most comfortable direction.
(
   Sum( {< Causa=, EsPlanificada=, EsMicroparada=, Estacion= >} MinutosProgramados )
 - Sum( {< EsPlanificada = {0} >} MinParada )
)
/ RangeMax( Count( {< EsPlanificada = {0} >} DISTINCT ParadaID ), 1 )

// ---- Real availability ----
1 -
  Sum( {< EsPlanificada = {0} >} MinParada )
/ RangeMax(
    Sum( {< Causa=, EsPlanificada=, EsMicroparada=, Estacion= >} MinutosProgramados )
  , 1 )

// ---- Availability WITHOUT micro-stops (the manual report number) ----
// Put it next to the previous one. The difference between them
// is the exact size of your blind spot.
1 -
  Sum( {< EsPlanificada = {0}, EsMicroparada = {0} >} MinParada )
/ RangeMax(
    Sum( {< Causa=, EsPlanificada=, EsMicroparada=, Estacion= >} MinutosProgramados )
  , 1 )

The block with Causa=, EsPlanificada=, EsMicroparada=, Estacion= is the most commonly forgotten piece of a QlikSense downtime analysis. It is also the one that does the most damage. The fields cleared inside the braces free the denominator from the user’s selections. Without it, the indicator gets more favorable precisely when someone tries to investigate a specific cause. I have seen it happen in dashboards that had been in production for a year.

The Pareto that tells you where to act

The rule of thumb that organizes any QlikSense downtime analysis is a solid one: roughly 80% of downtime minutes come from 20% of the causes, and in packaging plants the concentration is even higher, closer to 82/18 according to European references. Still, the value of the Pareto is not in the chart but in the cumulative percentage. That number tells Maintenance when to stop adding causes to the work list.

// ---- Cumulative % of minutes, with the Causa dimension
//      sorted descending by downtime minutes ----
RangeSum(
   Above( TOTAL
      Sum( {< EsPlanificada = {0} >} MinParada )
    , 0, RowNo(TOTAL)
   )
)
/ RangeMax( Sum( {< EsPlanificada = {0} >} TOTAL MinParada ), 1 )

// ---- Concentration index: how much the top 3 causes weigh ----
// Above 70% = high concentration: attacking three causes captures
// most of the improvement available. Below 50% = the problem
// is spread out and the Pareto is not going to save you.
Sum(
  Aggr(
     If( Rank( Sum( {< EsPlanificada = {0} >} MinParada ) ) <= 3
       , Sum( {< EsPlanificada = {0} >} MinParada ) )
   , Causa
  )
)
/ RangeMax( Sum( {< EsPlanificada = {0} >} TOTAL MinParada ), 1 )

The concentration index is, in my experience, the most underrated indicator in the whole QlikSense downtime analysis. When it goes above 70% the management conversation changes tone: it is no longer about whether something must be done, but about which of the three causes to attack first. It is triage, and it works the same way as in an emergency room: you are not seen in order of arrival, you are seen by severity.

Translating it into money: what management gains

A well-built QlikSense downtime analysis produces four measurable effects, and none of them is «more visibility». First, the focus effect: programs that work off a Pareto of causes report reductions of 35% to 50% in total downtime within twelve weeks, not twelve months. Then comes resource allocation. With MTTR by station you know where spare parts are missing from the warehouse and where shift training is missing. Those are two different problems with different solutions. Measured at plant level, the number mixes them together.

Third comes the negotiation with the board. When the CostoParada field is priced, the investment request stops being «we need a critical spare part». It becomes «these 14 stoppages cost 38 million pesos and the spare part costs 4». That conversation wins itself.

The fourth effect is more uncomfortable and at the same time more valuable, because once you measure properly the indicator gets worse, and a plant that reported 94% availability for years is going to show 78% in the first week of the new dashboard, with nothing having changed in the machinery or the people. You have to prepare that moment. A good dashboard that nobody defends politically dies in the first meeting.

Common mistakes in QlikSense downtime analysis

⚠️ Common error: using calendar time as the availability denominator. A shift that was not scheduled is not downtime. With 24 hours in the denominator at a plant running two shifts, availability is understated by about a third and the indicator is useless.

Putting planned stops into the MTBF. MTBF measures equipment reliability between failures. A scheduled cleaning is not a failure. Including it degrades the indicator for doing things right. And that is how you lose Maintenance at the first review.

Reporting MTTR only as an average. The distribution of repair times is heavily skewed: many 10-minute interventions and a few 9-hour ones. So the average lands in the middle and describes nobody. It is worth putting the median and the 90th percentile next to it with Fractile(). P90 defines the commitment you can offer Production.

Calculating MTBF from too few events. When there are fewer than 10 stoppages in the period, the number moves so much that it no longer means anything. It is worth adding a condition to the object, or showing the event count next to it, always.

An open cause catalog. If the operator can type free text, in six months you will have 300 different causes, 40 of them spelling variants of «jam». The Pareto never converges and the dashboard becomes useless. Closed catalog, 20 to 25 causes maximum, reviewed twice a year.

Best practices for sustaining the QlikSense downtime analysis

Automatic capture with a low threshold. Log from 30 seconds, not from 5 minutes. Manual logging loses between 60% and 70% of real downtime. That is why starting with the PLC is the condition for everything else to make sense.
MTTR and MTBF by station. The plant-level number works for the monthly report and for nothing else. The operating decision lives at station or equipment level.
Two availability figures on the same sheet. With and without micro-stops. The gap between them is the strongest argument you will have for justifying instrumentation.
Alert on trend, not on threshold. An MTBF that falls 30% over four weeks predicts a major failure better than any absolute value. You implement it by comparing, with Set Analysis, the MTBF for the period against that of the previous four weeks.
Priced and reviewed cost. The rate table in MAP_CostoMinuto is signed off by Costing, not IT. And it gets reviewed when the sales price changes, because the opportunity cost of an hour of downtime rises with the margin.
A log of definition changes. Every time a cause moves from planned to unplanned, history changes. Leave the date of the change in the script as a comment. Otherwise you will spend a morning explaining why March’s number is no longer March’s number.

What the shift already knew

There is a pattern that repeats at every plant where I have implemented this. When the dashboard finally shows real availability, management is surprised and the operators are not. Because they lived with the micro-stops every day, and the only thing missing was a number that made them exist for the rest of the organization.

That, in the end, is the job of a good QlikSense downtime analysis: giving accounting language to what the plant already knows. The rest follows on its own.

Take the downtime history of your most critical line. Calculate availability with and without events under five minutes, and put the two numbers side by side. If the gap is more than 10 points, you already have your business case written. More practical material of this kind is at hectorpincheira.com.