Sometimes an operator needs to watch a specific handful of values that no single dashboard shows together, maybe a pressure on one site, a flow on another, and a couple of related tags scattered across the fleet, all while chasing down one particular problem. A tag watchlist is the scratchpad for exactly that: an ad-hoc list an operator assembles on the fly, pulling tags from anywhere onto one live view, without touching the permanent dashboards everyone else relies on. It exists for the duration of the task, is owned by the person who made it, and disappears when it is no longer needed, which is what makes it different from a fixed, designed screen.
Tag Watchlist in one line: A tag watchlist is an operator-created ad-hoc list of tags, often drawn from many different sites, gathered onto a single live view for troubleshooting or watching a specific event, without editing the permanent dashboards. It is transient and user-owned rather than a designed screen: tags are quick-added from search, the list can be personal or shared, and any tag on it can be trended in one click. It is a scratchpad for monitoring, not part of the fixed layout.
The defining feature of a watchlist is that the operator builds it in the moment, for a reason that exists right now, and is not anticipated by any permanent screen. When a problem crosses sites, a suspected leak affecting a pressure here and a flow there, a cluster of wells behaving oddly, an operator wants those specific tags side by side immediately, and no designed dashboard happens to show that exact combination. A watchlist lets the operator gather them anyway, pulling each tag from wherever it lives onto one live list, so the values that matter for this task are finally in one place at one time.
Assembling a watchlist has to be fast, because its whole value is being available exactly when a question arises. Quick-add from search is the usual mechanism: the operator searches for a tag by name or by site, finds it, and drops it onto the current watchlist in a couple of actions, then repeats for the next tag, building the list as the investigation suggests new things to watch. The list updates live like any other view, showing current values as they change, so once a tag is added the operator is watching it in real time. Adding and removing tags is meant to be lightweight, matching the quick, evolving nature of troubleshooting.
Crucially, none of this touches the permanent dashboards, and that separation is the point. The designed screens that operators and reports depend on stay exactly as they were, because a watchlist is a personal overlay, not an edit to shared configuration. An operator can freely gather any combination of tags for a private investigation without risk of disturbing the standard views, and without needing anyone's permission to change a shared screen. The watchlist is a place to look, assembled by and for the person looking, kept entirely apart from the fixed layout the rest of the operation runs on.
A watchlist is usually personal by default, belonging to the operator who made it, which fits its role as an individual scratchpad. One operator's investigation should not clutter another's view, so each person keeps their own watchlists, builds them for their own tasks, and clears them when done. This private ownership is what lets a watchlist be casual and disposable: there is no coordination cost to creating one, no shared artifact to manage, and no worry about stepping on a colleague, because the list is yours alone and affects no one else.
Some situations do call for a shared watchlist, and the ability to promote one from personal to shared covers them. During a significant event, a startup being closely watched, an upset being managed by a team, a call with several people looking at the same problem, it helps for everyone to see the identical set of tags, so a shared watchlist becomes a common view assembled for that event and visible to the group. The distinction is intent: personal watchlists are for one person's ongoing troubleshooting, and a shared watchlist is a deliberate, temporary common focus for a team, still transient but visible to more than its creator.
The feature that makes a watchlist a genuine investigation tool rather than just a list of numbers is one-click trending. A live value tells the operator where a tag is now, but troubleshooting almost always needs where it has been, so being able to click a tag on the watchlist and immediately see its trend closes that gap. From the same scratchpad the operator gathered, they can pivot any entry into its history, compare how two tags from different sites have moved over the same window, and follow the thread of a problem through time. That tight loop, gather the suspect tags, then trend them on demand, is what turns a watchlist from a static readout into the working surface of an investigation.
A watchlist fills a gap that fixed dashboards structurally cannot, because dashboards are designed in advance for expected situations while troubleshooting is by nature unexpected. No one draws a screen for the specific, one-off combination of tags an operator needs during a particular incident, and it would be absurd to try, so without a watchlist the operator is left flipping between screens and holding the correlations in their head. The watchlist gives them a purpose-built surface for the situation in front of them, assembled in seconds, which is exactly the tool an investigation needs and a designed dashboard can never be.
In a cloud SCADA platform such as Merobix that presents a whole remote fleet in one place, watchlists shine because the tags an operator needs to correlate are often scattered across many sites. Chasing a problem that spans several remote wells or comparing behavior between two stations means pulling tags from different corners of the fleet, and a watchlist lets an operator do exactly that, quick-adding points from any site onto one live view regardless of where they physically are. For an operator responsible for many remote assets, that ability to instantly gather a custom cross-site view is often the fastest path from a vague symptom to a located cause.
The transient, personal nature of the watchlist is a feature, not a limitation, because it keeps the tool frictionless and the shared configuration clean. An operator spins up a watchlist for a task, works the problem, and abandons the list when the task is done, leaving no residue in the permanent screens and no maintenance burden behind. There is no design review, no naming standard to honor, no risk of the fleet's dashboards accumulating one-off clutter from every past investigation. The watchlist is meant to be created freely and discarded freely, and that disposability is precisely what makes it the right instrument for the fast, unplanned work of troubleshooting a live fleet.
A dashboard is a designed, permanent screen built in advance for an expected situation and shared across the operation, whereas a watchlist is an ad-hoc, transient list an operator assembles in the moment for a specific task. The watchlist is user-owned and disposable, pulls tags from anywhere onto one live view, and disappears when the task is done, all without touching the fixed dashboards everyone else relies on. It is a scratchpad, not part of the standard layout.
Usually not by default, because watchlists are typically personal, belonging to the operator who created them, which keeps one person's investigation from cluttering another's view. When a situation calls for a common focus, such as a team managing an upset or a call where several people watch the same tags, a watchlist can be shared so the group sees the identical set. The distinction is intent: personal for individual troubleshooting, shared for a deliberate temporary team view.
Yes, and one-click trending is what makes a watchlist a real investigation tool rather than just a live readout. Because troubleshooting needs history as well as the current value, clicking a tag on the watchlist to see its trend lets an operator pivot straight from where a value is now to where it has been, and compare tags from different sites over the same window. That tight loop of gathering suspect tags and trending them on demand is central to how a watchlist is used.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.