Understanding alerts

An alert is TaktSignal saying: this is likely to cost factory time, here is why, here is the evidence, and here is how sure we are. Alerts are decision support. They can be wrong, late or missing — always check them against ERPNext and the floor before acting.

Alert types

Alert	Raised when	Time at stake means
Material shortage	Open work orders need more of a material than is usable in stock plus supply arriving in time	Hours orders would wait between the need and the date supply covers it (an estimate)
Work-center overload	Scheduled work exceeds the available hours of a work center on a day	Hours of queue beyond capacity
Late start	A released work order has not started by its planned start	Working hours since the planned start
Late completion	A work order is projected to finish after its planned end	Projected slip
WIP aging	Work in progress has shown no progress for too long	Working hours without progress
Blocked operation	An operation cannot start because something upstream is not done	Time to clear (an assumption where no better data exists)
Customer delivery risk	A sales order is projected to be ready after its promised date	Hours past the promise — a consequence, not added to factory time
Inventory trust	A material's recorded stock is doubtful (count mismatches, unexplained variance)	None — a data warning

Severity (Critical, High, Medium, Low) combines how soon, how much time and how much downstream work is affected. Alerts below the minimum time impact that touch no customer order are downgraded, so the list stays short.

Reading an alert

Open an alert to see:

• Why it exists — the rule and the facts that triggered it, in plain language.
• Evidence — the ERPNext documents involved (work order, BOM, stock, purchase order…) with their numbers.
• Affected time window — when the impact is expected to start ("impact in 30 h"), and how early the alert was raised.
• Time at stake and its basis — an estimate, with the calculation written out. Not measured downtime.
• Confidence — High, Medium or Low, with every reason that lowered it. (Understanding confidence)
• Affected orders — the work orders and customer orders it touches.
• Suggested next step — where to look. TaktSignal never executes anything.
• Timeline — detection, severity changes, who did what.

Verifying an alert

Before acting, spend a minute checking:

1. Freshness. Is the data behind it recent? The dashboard freshness line and the alert's confidence reasons say so. If ERPNext was updated a few minutes ago, click Sync now first.
2. ERPNext. Open the documents named in the evidence. Do the quantities, dates and statuses match?
3. The floor. Is the material really missing, the machine really idle, the order really waiting? ERPNext is often behind reality; so is TaktSignal.
4. Assumptions. Confidence reasons such as assumed calendar or unconfirmed ETA tell you what TaktSignal had to guess.

If the alert is wrong, resolve it as false positive or mark it incorrect — and tell us what was different (without customer data): that is exactly the feedback Community Alpha needs.

The alert workflow

Status	Meaning
Open	New, nobody has looked yet
Acknowledged	Seen
In progress	Someone owns it and is working on it
Snoozed	Hidden until a chosen time (it returns if it gets worse)
Resolved	Closed by a person, or automatically when the condition is gone

Alerts update themselves as data changes: they escalate or de-escalate, resolve automatically when the condition disappears (not while the data behind them is incomplete) and reopen if it comes back.

When resolving, record the outcome — resolved before impact, caused delay, false positive, not actionable, supplier expedited, production rescheduled, alternative material, other — and whether the alert was correct, partially correct, incorrect or there was not enough data.