Developer ToolsFree generatorPDF, Excel, Word export

Lean KPI SQL Query Generator for Downtime Pareto and Availability

Every OEE improvement starts with a Pareto of lost minutes. This generator writes three SQL queries from your own table and column names: a reason code Pareto, availability by work center, and the top work center and reason pairs. Copy them into your reporting tool.

Fill in

Your table holding one row per stop.

SQL Server style by default. Use your database's date difference function.

Example: 14 days x 24 hours x 60 minutes.

Generated code
Download:

1. Downtime Pareto by reason code

-- Downtime minutes ranked by reason, with cumulative share
WITH d AS (
  SELECT reason_code AS reason,
         SUM(DATEDIFF(minute, start_time, end_time)) AS minutes
  FROM mes_downtime_event
  WHERE start_time >= '2026-10-01'
    AND start_time <  '2026-11-01'
  GROUP BY reason_code
)
SELECT reason,
       minutes,
       ROUND(100.0 * minutes / SUM(minutes) OVER (), 1) AS pct_of_total,
       ROUND(100.0 * SUM(minutes) OVER (ORDER BY minutes DESC ROWS UNBOUNDED PRECEDING)
             / SUM(minutes) OVER (), 1) AS cumulative_pct
FROM d
ORDER BY minutes DESC;

2. Availability by work center

-- Availability = (planned minutes - downtime minutes) / planned minutes
SELECT work_center AS work_center,
       SUM(DATEDIFF(minute, start_time, end_time)) AS downtime_minutes,
       20160 AS planned_minutes,
       ROUND(100.0 * (20160 - SUM(DATEDIFF(minute, start_time, end_time))) / 20160, 1) AS availability_pct
FROM mes_downtime_event
WHERE start_time >= '2026-10-01'
  AND start_time <  '2026-11-01'
GROUP BY work_center
ORDER BY availability_pct ASC;

3. Top work center and reason pairs

-- Where does the largest loss sit?
SELECT work_center AS work_center,
       reason_code AS reason,
       COUNT(*) AS stops,
       SUM(DATEDIFF(minute, start_time, end_time)) AS minutes
FROM mes_downtime_event
WHERE start_time >= '2026-10-01'
  AND start_time <  '2026-11-01'
GROUP BY work_center, reason_code
ORDER BY minutes DESC
LIMIT 10;

Table and column names here are generic placeholders, not a specific ERP schema. Replace them with your own. LIMIT is MySQL, PostgreSQL and SQLite syntax; on SQL Server use SELECT TOP and on Oracle use FETCH FIRST. The duration expression must match your database. Open stops with no end time need handling. Test on a copy, read only, before using the numbers.

Run these queries in plain language

Optional: see how a natural language layer can generate and explain this kind of query on your own data.

Optional. The tool and every export work without this. No spam.

How to use the generator

Enter the name of the table that holds one row per stop, then the columns for work center, reason and start time. Set the duration expression to match your database. Choose the date range with an exclusive end date and the planned production minutes for that period. Copy the generated SQL into a read only connection to a reporting replica or data warehouse, never into a live transactional database during peak load.

What the queries calculate

The Pareto query sums downtime minutes by reason, then calculates each reason's share of the total and a running cumulative share, so you can see which few reasons cause most of the loss. The availability query uses the standard formula: planned minutes minus downtime minutes, divided by planned minutes. The third query shows the work center and reason pairs with the highest minutes, which tells you where to send the first improvement team.

  • Pareto: ranks reasons and shows cumulative percent.
  • Availability: planned minutes less downtime, over planned minutes.
  • Pairs: pinpoints machine and cause together.

Data quality checks before trusting results

Check that every stop has an end time, that overlapping events on the same work center are not double counted, and that planned downtime such as breaks is excluded or coded separately. Compare the total to shift calendars. If one reason such as Other dominates, the codes need improvement before the Pareto is useful. Run the same query for two periods to see whether the shape is stable.

Common mistakes

Do not use a period where the planned minutes differ by work center without adjusting; the single planned minutes field in this generator assumes the same schedule. Avoid mixing time zones between the event table and your date filter. Also avoid acting on a few days of data, because short stops and rare breakdowns need weeks to show a stable pattern.

Frequently Asked Questions

Does this work with my ERP or MES schema?

It uses generic table and column names that you replace with your own, so it fits any relational schema that records one row per stop with a reason, work center, start and duration. It does not assume a specific vendor schema.

How is availability calculated?

Availability equals run time divided by planned production time. Run time is planned time minus downtime. The query computes it as planned minutes minus downtime minutes, divided by planned minutes, and shows the result as a percent.

Why does the Pareto show a cumulative percent?

The cumulative percent shows how many reasons it takes to reach a given share of total loss, often about 80 percent from a few reasons. It helps you choose where to focus instead of treating every reason equally.

Can I use it for scrap instead of downtime?

Yes. Point the table at a scrap or reject table, the reason column at the scrap reason, and replace the minutes expression with a quantity or cost column. The same Pareto logic applies to any ranked loss.

If you would rather ask for these numbers in plain language against your ERP or MES, ERPray can show the generated query and stay read-only on your own servers.