Skip to content

Shutdowns

Review reported equipment shutdowns, log planned shutdowns (maintenance windows), and analyse shutdown patterns.

Required role

Supervisor or Admin can create, edit, and resolve shutdowns. Manager and Viewer have read-only access.

Overview

The Shutdowns page is where every reported or planned shutdown lives until it's resolved, and where you see historical shutdown data after. Technicians raise shutdowns from mobile; supervisors triage, act, and close them.

Shutdown data drives the Shutdown Report, Asset Availability, and OEE Report — it's the single most important input for availability and downtime metrics.

Prerequisites

  • Shutdown reasons have been configured in Master data.
  • You have the appropriate role (Supervisor / Admin for writes, Manager / Viewer for reads).

Open the shutdowns page

Shutdowns in the sidebar. The list shows:

Column Meaning
# Row number.
Line Affected production line.
Asset Affected asset.
Reason From master data.
From Start time.
To End time (blank if still open).
Status Open / Resolved.

Top-right controls: a Show history checkbox (toggles between open-only and all shutdowns) and an Add Shutdown button.

Reported-by, resolved-by, and priority details appear on the shutdown's detail page after you click through a row — they're not columns in the top-level list.

The default view shows Open shutdowns first. Toggle filters to see resolved or specific lines.

Triage an incoming shutdown

When a technician reports a shutdown from mobile:

  1. You receive a push notification (if you have the category on).
  2. The shutdown appears at the top of the list with status Open and a red indicator.
  3. A Critical priority shutdown also flashes the affected line on the Dashboard.

Review quickly

Click the row. You see:

  • Reason and description from the reporter.
  • Photos (if attached).
  • Safety concerns (if flagged).
  • Start time.
  • Affected asset / line.

Decide the next action

  • Dispatch a technician if nobody's on it. Create an assignment from the shutdown's Actions → Assign repair.
  • Cross-link to a repair request if the reporter raised one alongside.
  • Escalate if Critical — alert the safety officer, plant manager, or whoever your playbook says.
  • Update the shutdown with any supervisor-side context.

Mark resolved when production resumes

  1. Open the shutdown.
  2. Click Resolve.
  3. Fill in:
    • End time — when production actually resumed.
    • Resolution notes — brief summary of what was done.
    • Resolved by — the person or team credited with the fix (auto-pre-fills to you).
  4. Save.

The status changes to Resolved and the shutdown moves to historical view.

Log a planned shutdown

Ahead of scheduled maintenance windows:

  1. New shutdown.
  2. Select the line or asset(s) affected.
  3. Pick a shutdown reason: Planned maintenance (or whatever your master data lists).
  4. Set Start and End to the planned window.
  5. Tick Planned.
  6. Save.

A planned shutdown tells reports to exclude the window from unplanned-downtime metrics. If the actual window runs longer, update the end time post-facto.

Edit an open shutdown

Open a shutdown → Edit. You can change every field except Reported by (audit integrity).

Changes are logged — anyone who looks at the history sees who edited what and when.

Shutdown-to-repair-request linkage

If the technician raised a repair request for the same incident, it's auto-linked if:

  • Same asset.
  • Submitted within a short window of each other.

You can also link manually: open the shutdown → Link repair request → pick the relevant one.

Linked records cross-reference in reports.

Filtering and searching

The filter bar lets you scope by:

  • Status — Open / Resolved / All.
  • Priority.
  • Line / Asset.
  • Date range — for historical analysis.
  • Planned / Unplanned.
  • Reason (from master data).

Use the date range plus line filter to ask "how much downtime did Line 3 have last month?".

Bulk actions

Rare but occasionally useful:

  • Resolve selected — batch-close old open shutdowns that should have been closed earlier.
  • Export selected — CSV for external analysis.

Reports driven by this data

  • Shutdown Report — incidents by reason, duration, frequency.
  • Asset Availability — uptime % per asset, computed as (total time − open-shutdown time) / total time.
  • OEE Report — availability component comes directly from shutdown durations.

Because reports depend on accurate start / end times, keep shutdowns up to date. A shutdown left "open" for days because nobody updated its end time destroys availability metrics for that asset.

Things to watch for

Close shutdowns promptly

An open shutdown counts as downtime. If you forget to mark resolved, availability numbers collapse. Build a habit of checking the Open shutdowns list at shift end.

Plan before you stop

Any shutdown you can schedule in advance should be logged as Planned before it happens. Retrofitting "it was planned" after the fact damages data integrity.

Escalation isn't automatic

A Critical shutdown notifies via push but doesn't page your on-call rotation. Set that up outside the platform (PagerDuty / Opsgenie / phone tree) and reference the shutdown record in your playbook.

Common patterns

Daily opener

  1. Open Shutdowns.
  2. Sort by start time descending.
  3. Any open shutdowns from the previous shift that should have been closed — close them now, or ask the incoming shift to.
  4. Scan new ones and triage.

Weekly review

  1. Filter by date range = last 7 days, Resolved.
  2. Sort by duration descending — the longest downtime events.
  3. Look for patterns:
    • Same reason repeating → is there a standing issue?
    • Same asset recurring → asset-level problem?
    • Same technician resolving → load concentrated?

Post-incident learning

After a significant shutdown:

  1. Document the timeline in the shutdown's resolution notes.
  2. Link to any repair requests generated from it.
  3. Share summary in your next team meeting — cross-referencing the shutdown by ID makes context easy to retrieve.

Troubleshooting

Problem Fix
Shutdown appears twice A technician submitted twice; merge by resolving the duplicate with note "duplicate of #N"
OEE report drops unexpectedly Check for an open shutdown someone forgot to close
Push alert didn't arrive Confirm your notification category is on; see Notifications
Can't resolve — button greyed out End time missing; fill it in first