Values Spike at the Same Time Daily: Diagnose It

Back to Blog

First Checks: Pin Down the Timing and Scope

Record the exact time of the spike over several days and check whether it is fixed to the clock or drifts. A spike that lands at precisely the same clock time every day is tied to something scheduled by a timer or a control system. A spike whose time slides earlier or later day by day, tracking sunrise or sunset, is tied to the sun. This single distinction - fixed clock time versus sun-tracking time - splits the entire diagnosis into two branches before you look at anything else, and it costs nothing but a few days of the trend you already have.

Map how many tags spike together and what they share. A single tag spiking alone points at that tag's own wiring or sensor being disturbed. A group spiking together points at a shared cause reaching all of them - a common power event, a shared cable route, or a system-wide task. Tags on the same physical cable tray or the same input card that spike in unison are telling you the disturbance is coupling in through their shared physical path, which is a very different fix from a genuine process event that would show up on process grounds.

Note the shape of the spike. A brief, sharp transient that appears for one or two samples and vanishes is an electrical or communication artifact. A broader bump that rises and falls over minutes may be a real thermal or process effect. A spike that coincides with a known daily operation - a pump starting, a heater cycling, a batch step - may be entirely real and expected. Reading the shape alongside the timing keeps you from chasing a true process event as if it were noise; not every daily pattern is a fault.

Scheduled Loads, System Tasks, and Sun-Driven Effects

Take the fixed-clock-time branch first, and suspect a scheduled electrical load. Equipment that switches on at the same time daily - irrigation, heaters, large motors, lighting contactors - draws inrush current and can couple electrical noise onto nearby signal wiring, especially analog loops sharing a tray or a poor ground. The spike appears on the measurements, not because the process changed, but because the signal was disturbed. If the spike lands on many analog tags at the switch-on instant and clears immediately, this coupling is the leading suspect, and it connects to the broader problem of noise appearing on many analog tags at once.

Still on the fixed-time branch, consider a periodic system or communication task. A scheduled backup, a nightly database job, a daily poll reconfiguration, or a heavy report run can load the poll engine, the network, or the historian at a fixed time, disturbing update timing and occasionally producing artifacts in the data. The tell is that the spike aligns with a known scheduled task rather than a field event, and it may show as a timing disturbance - values stuttering or jumping - rather than a clean process excursion. Checking the schedule of system jobs against the spike time catches this quickly.

Now the sun-tracking branch. A spike whose time drifts across the year with sunrise or sunset is almost always a solar or thermal effect. Direct sun on an unshaded transmitter, a junction box, or an exposed cable run heats it at a predictable time and can shift a reading; a solar-powered site may show a charging artifact when the panel comes into or out of sun. On instruments, thermal expansion and radiant heating produce a bump that tracks the sun rather than the clock. If your spike arrives at dawn and moves with the season, look at sun exposure and shading before you suspect anything electrical.

Verifying the Cause and Confirming the Fix

Verify by correlating the spike against the suspected schedule directly. Overlay the daily spike time on the run status of the suspected load, the schedule of the suspected system task, or the position of the sun. A clean correlation - the spike appears exactly when the load switches, the job runs, or the sun hits - confirms the cause. The absence of a spike on a day when the load did not run, the job was disabled, or the sky was overcast is the strongest confirmation of all, because it is a natural controlled test the environment ran for you.

Distinguish a data artifact from a real recurring event before you fix anything, because the fixes are opposite. If the spike is an artifact - coupled noise, a system-timing disturbance, sun on a transmitter - the fix is to remove the disturbance or reject it, by improving grounding and shielding, rescheduling the task, shading the instrument, or applying a spike-rejection filter such as a median filter to the affected tags. If the spike is a real daily process event, the data is correct and the fix, if any, is on the process side, not the instrument. Filtering a real event hides information you may need.

In a cloud SCADA such as Merobix, a daily-recurring spike is easy to characterize because the historian holds a long, dense trend that makes the repetition and its exact timing obvious, and multiple tags can be overlaid to see whether a group moves together. An engineer can align the spike against a load's run status or a system schedule in the same view and confirm the correlation, then watch the pattern disappear after the disturbance is removed. The long trend is what turns a vague daily annoyance into a precisely timed, provable correlation.

When to Escalate

Escalate to an electrical or instrumentation technician when the spike correlates with a switching load and points at grounding, shielding, or cable routing, because those are field fixes requiring hands on the wiring. Give them the spike time, the affected tags, and the correlated load so they can target the specific coupling path rather than surveying the whole installation.

Escalate to the system or IT owner when the spike aligns with a scheduled backup, database, or reporting job, because rescheduling or lightening that task is a system-side change. And escalate nothing at all when the daily pattern turns out to be a real, expected process event - in that case the correct outcome is to document it as normal so the next person does not re-diagnose a healthy pattern as a fault. Knowing when there is nothing to fix is part of the tree.

Frequently Asked Questions