An operator glances at the HMI and sees a value flagged Bad - grayed out, marked with a symbol, or replaced by a dash. The number might still be showing, but the system is warning that it no longer trusts it. Bad quality is SCADA's way of saying do not believe this reading, and knowing what forces it and how to clear it is one of the most practical troubleshooting skills a technician can have. This page is the plain-language entry point: what Bad actually means on the screen, the chain of things that make a tag go Bad, and how it differs from Good and Uncertain.
Bad-quality tag in one line: A bad-quality tag is a SCADA point whose value the system has flagged as untrustworthy, so operators know not to rely on the displayed number for decisions or control. A tag goes Bad when the system cannot vouch for the value - most often because communication to the source device was lost, but also from configuration errors, a device or sensor fault, or a reading outside the point's valid range. Clearing it means fixing the underlying cause so a trustworthy value flows again.
Every SCADA value carries more than a number. Alongside the measurement sits a quality flag - a small piece of metadata that says whether the value can be trusted - and a timestamp. The three travel together, and the quality flag is the part that tells an operator whether the reading is dependable. Good means the system stands behind the value. Bad means it does not: something in the chain from sensor to screen has broken down badly enough that the displayed number cannot be relied upon. HMIs usually make Bad visually obvious - graying the value, showing a dash or an asterisk, changing its color - precisely so an operator does not act on a stale or meaningless reading.
This matters because a Bad flag is a safety and integrity feature, not a nuisance. A tank level that still shows its last number but is flagged Bad is telling the operator that the figure is frozen or unverifiable and should not drive a decision. Without the quality flag, that last-known number would look exactly like a live one, and someone could act on a value that is minutes or hours out of date. The whole point of Bad quality is to make the difference between a trustworthy reading and an untrustworthy one impossible to miss on the screen.
By far the most common reason a tag goes Bad is a communication loss. If the SCADA server stops being able to reach the device that sources a point - a timed-out poll, a dropped link, a failed gateway - it cannot get a fresh value, so it flags every affected tag Bad rather than pretend the last value is current. This is why a whole block of tags often goes Bad together: they all live behind the same device or link that just dropped. When comms are the cause, the fix lives in the connection, and every tag on that device typically recovers at once when the link comes back.
Beyond comms, a handful of other conditions push a tag Bad. A configuration error - a tag pointing at a register or address the device does not actually have - can make the source refuse the request, and the point ends up Bad because no valid value ever arrives. A device or sensor fault at the source, such as a failed transmitter or an input card reporting a fault, propagates up as Bad quality. A reading outside the point's valid range, or a sensor signal below or above its defined limits, can be flagged Bad because the value is physically impossible or unmeasurable. The practical diagnostic move is to ask whether one tag is Bad or many: many tags Bad together usually means a shared comms or device problem, while a single Bad tag among healthy neighbors points to that one point's configuration, sensor, or range.
Bad quality is not something you acknowledge away - it clears when the underlying cause is fixed and a trustworthy value flows again. So clearing a Bad tag is really a diagnosis: find why the system cannot vouch for the value and remove that reason. If it is comms, restore the link or fix the device that dropped; if it is configuration, correct the address the tag polls; if it is a sensor or range problem, service the instrument or check why the signal left its valid band. Once a good value arrives, the quality flag returns to Good on its own. Trying to force a Bad tag green without fixing the cause just hides the warning.
This is exactly where visibility earns its keep, and where a cloud platform helps. It matters to an operator that the system shows not just that a tag is Bad but why - which device dropped, when it dropped, whether one point or a whole group went Bad together - because that turns a red flag into a starting point. A cloud SCADA platform such as Merobix carries the quality flag with every value from the field to the browser and preserves it in history, so a Bad reading is never mistaken for a live one, and an operator can see whether the cause is a lost link, a misconfigured point, or a failing instrument. That grouping and context is what makes clearing a Bad tag a quick, targeted fix rather than a guessing game.
Most often because communication to the source device was lost, so the system cannot get a fresh value and flags the tag Bad rather than show a stale one as if it were live. Other causes are a configuration error pointing the tag at an address the device does not have, a sensor or device fault at the source, or a reading outside the point's valid range. Whether one tag or many went Bad together tells you if it is a shared comms problem or a single-point issue.
You clear it by fixing the underlying cause, not by acknowledging it - the flag returns to Good on its own once a trustworthy value flows again. Restore the communication link, correct a misconfigured address, or service a faulty sensor depending on what forced it Bad. Forcing a tag green without addressing the cause just hides a real warning.
Bad means the system does not trust the value at all - something broke badly enough that the reading cannot be relied on, such as lost comms. Uncertain sits between Good and Bad: a value is available but questionable, for example a sensor slightly over range or data that is stale but not yet lost. A Bad value should not be used; an Uncertain one should be treated with caution and not trusted for control or billing.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.