A no-data alarm should trigger when more time has passed since the last valid measurement than the actual cadence, transmission method and channel risk allow. It does not say that the sensor is broken or that the structure is at risk. It says something more basic: the system has lost observability and cannot confirm the current state.
In short
NO_DATAis a separate data-quality state, not a low structural alarm level.- Timeout should come from cadence and transmission buffer, not from one value set for the entire project.
- Missing data can affect a channel, a group of channels, a device or the entire site; scope helps identify the cause.
- Backfilled history restores the chart, but it does not erase the period when the operator did not have current information.
- A good procedure ends with data restoration and gap assessment, not with restarting the device alone.
The most dangerous chart is the one that stopped quietly
A no-data alarm is a rule that detects that no new, valid measurement has appeared from the expected source for a defined period. Its purpose is to protect observability, not to diagnose a failure.
A typical dashboard keeps the last known value. If the line is drawn up to the last point, the user may see a calm section and assume the asset is stable. In reality, the sensor may have stopped measuring, the logger may have lost power, the modem may have lost coverage, the clock may have drifted beyond tolerance, or the platform may reject a frame with the wrong structure.
"No alarm" therefore has two possible meanings:
- current data arrived and no value exceeded the threshold;
- there is no current data, so the threshold rule had nothing to evaluate.
A system that does not distinguish between these states is blind exactly when the user most needs certainty. USACE and FERC guidance on dam instrumentation stresses the importance of regular collection, prompt review and response to inconsistencies. The principle is universal: an instrument is useful only when you know that it works and when it was last read reliably.
NO_DATA is not a device diagnosis
In an illustrative message, it is better to write "no new data for 64 minutes" than "sensor failure". The second description is a conclusion without proof. Possible causes sit at several layers.
| Layer | Example cause | Evidence to check |
|---|---|---|
| Sensor | damage, no excitation power, disconnected lead | input status, other channels on the same device, field check |
| Logger | restart, full memory, wrong configuration, power loss | last communication, status, local log |
| Time | clock outside tolerance, wrong time zone, ambiguous timestamp | device time, UTC, validator response |
| Transmission | no coverage, carrier issue, broken network | heartbeat, modem log, other devices at the site accessible |
| Data frame | wrong structure, missing field, different data count than timestamps | response code, saved request and response, cryptographic content hash |
| Platform | queue, processing error, service unavailable | application monitoring, error log, data from other projects |
| Configuration | channel disabled, identifier changed, wrong alarm range | change log and values before and after |
The scope of the missing data is the first clue. If one channel is silent and the others from the same device are fresh, the problem is closer to the input or configuration. If all channels from one device disappear, check the logger and power supply. If the whole site is silent, communications or shared power become the priority. If many independent sites stop at the same time, investigate the central layer.
This is still a heuristic. Do not close the ticket based only on the pattern. The evidence is the return of valid data and an explanation of the gap. For a vibrating wire channel, also use the procedure for diagnosing a missing and unstable vibrating wire sensor reading, which separates excitation, coil, cable, thermistor and telemetry.
How to size timeout to the actual cadence
The simplest useful rule looks like this:
timeout = actual cadence × tolerated missing count + transmission margin.
This is an organisational formula, not a standard. Every parameter needs a decision.
Actual cadence should come from data, for example from the median of intervals in a stable period. The logger setting may differ from practice. Tolerated missing count depends on criticality. Transmission margin covers batch sending, buffering, retries and normal delay.
Illustrative example
The channel has an actual cadence of 15 minutes. The logger sometimes sends two samples in one packet every 30 minutes. The team considers one delayed window acceptable, and the transmission margin is 10 minutes. An illustrative timeout can be:
15 min × 2 + 10 min = 40 min.
This is not a recommendation for the asset. If this channel decides whether excavation can continue, 40 minutes may be too long. If it is an auxiliary temperature during a shutdown period, a shorter timeout may create unnecessary noise.
Instead of one project-wide value, create classes.
| Class | Role of the data | Example timeout approach | Response |
|---|---|---|---|
| Operationally critical | affects the decision on work in progress | few tolerated misses, short margin | immediate verification with the duty contact |
| Important for diagnostics | supports interpretation and correlation | several intervals, depending on batch sending | service ticket within the agreed time |
| Auxiliary | context, does not drive response | longer window, periodic review | maintenance task |
| Planned outage | service or a phase outside scope | alarm muted until a specific date | automatic return to control after the deadline |
Do not copy values between classes. Copy the decision method.
Channel, device or whole project
An alarm can be defined at different levels. Each level answers a different question.
Channel: does a specific quantity have a new measurement? This matters when the device sends part of its inputs and one of them has frozen or been misconfigured.
Device: is the logger delivering any measurements at all? This limits a cascade of many channel alarms during a shared failure, but it can hide the loss of one critical input.
Data family: is the static or dynamic source sending the expected record type? The device may report correctly and still not deliver a specific stream.
Site or project: does the interruption cover a shared infrastructure point? Such an alarm often needs aggregation beyond a simple single-channel rule.
The best design uses a small number of high-level alarms and selected channel alarms for critical quantities. Sending dozens of SMS messages after one logger loses power worsens the response. At the same time, one device alarm without information on which critical channels disappeared makes prioritisation harder.
Illustrative post-alarm procedure: the first 15 minutes
The procedure should exist before the alarm goes live. A simple rhythm is a good start.
Minute 0-5: confirm scope
- check the time of the last valid measurement, not only the last activity;
- compare other channels on the same device;
- check other devices at the site;
- read the code of the last communication and the configuration change;
- acknowledge the alarm so the team knows who is acting.
Minute 5-15: assess the consequence
- determine whether a critical phase of the works or adverse conditions are underway;
- check an alternative proof: adjacent instrument, survey measurement, field observation;
- start contact with service and the person responsible for the decision;
- if the TARP requires it, reduce or stop the activity regardless of the assumed cause;
- record the decision and the evidence.
After data is restored
- check whether the source backfilled history or whether the gap remained;
- verify sequence and duplicates;
- assess whether a threshold breach occurred during the gap;
- do not erase the alarm trace just because the chart has filled in;
- adjust timeout only on the basis of the pattern, not a single incident.
The detailed mapping from trigger to responsibility is described in the article on the alarm response plan and TARP.
Backfilled history: good news, but not time travel
A modern logger can buffer measurements during a loss of connectivity. When the network returns, it sends the delayed records with their original timestamps. That is the right behaviour. It protects the completeness of history and allows you to assess what happened during the interruption.
It should not, however, automatically cancel the operational assessment. For two hours, the operator had no information. If the system was part of early warning, that fact remains a data-availability incident. The report should distinguish between:
- final completeness - how many samples exist after backfill;
- current freshness - how much time has passed since the last available sample at a given moment;
- delay - how late individual samples arrived;
- period of lost observability - when decisions were made without current data.
If these concepts are merged into one green percentage, the report hides risk instead of explaining it.
How to test NO_DATA before acceptance
It is not enough to unplug a cable and see a red colour. The test should have a predictable result.
- Record the current cadence and timeout.
- Safely pause one source while leaving others active.
- Measure the time from the last valid measurement to the state change.
- Check the content of the email and SMS: project, source, time of the last sample, level.
- Acknowledge the alarm with another user and verify the person and time.
- Restore the source without backfilling history; check the state transition and the visible gap.
- Repeat with buffering and history backfill; check sequence and duplicates.
- Mute the alarm until a short date and confirm the automatic end of the mute.
- Change the timeout, then recreate who changed it, when, and from what value.
- Check behaviour after restarting the platform and the logger.
Test both a missing channel and a whole device. They are two different failure types.
What this looks like in Inclify
Inclify has a NO_DATA alarm with a configurable window and the ability to point to a specific channel. The default window value is a starting point for configuration, not a safe standard for every asset. The data quality report helps establish the actual cadence and see gaps before you set the rule.
The state change is stored in history. Users receive email, SMS or an in-app notification according to their preferences and minimum level. The operator can acknowledge the alarm, which records the person and time, or mute it until a set date. The platform does not have an automatic escalation chain to additional people or native mobile push; these elements must come from the team procedure and available channels.
An administrator can check metadata and the saved request and response of the device, if the exchange falls within the configured retention period. By default, raw logs are kept for seven days. Measurements are a separate dataset and are not deleted together with the communication log. NO_DATA does not automatically point to the cause, it shortens the route to diagnosis and protects against confusing silence with stability.
Limitations of the NO_DATA alarm
NO_DATA answers only one question: whether a new, correctly accepted sample appeared within the expected time. It does not establish the cause of the absence and does not confirm that the earlier measurement was physically correct. A regularly arriving but frozen value may not trigger such a rule. The same applies to a miscalibrated sensor sending plausible-looking numbers.
That is why the data-presence alarm must be combined with checks of variability, comparison with neighbouring channels, review of references and periodic calibration assessment. A change in logger cadence also requires updating the window; otherwise a valid stream may start generating noise or a real gap will be detected too late. NO_DATA does not replace the local safety procedure, an alternative measurement or the engineer's assessment. The decision tree for further diagnostics is described in the guide how to check an incorrect sensor reading.
Checklist for configuring the no-data alarm
- What is the actual, not declared, cadence?
- Does the source send every sample, or batches?
- How many consecutive misses are acceptable for this decision?
- Is the channel critical, diagnostic or auxiliary?
- At what level do we alarm: channel, device or site?
- Who receives the information and who confirms takeover?
- What alternative evidence do we check during a gap?
- What do we do with work in progress until observability is restored?
- How do we mark planned service and when does the mute expire?
- How do we account for data backfilled later?
- Who assesses the gap after communication is restored?
- When do we review the timeout based on history?
If you do not know the answers to the first three questions, do not set 60 minutes arbitrarily. Look at the data first.
FAQ
What does the NO_DATA state mean?
It means that no new, valid measurement from the expected source appeared during the set window. It does not automatically mean a damaged sensor or an unsafe structural condition. It tells you that the system does not have the current evidence needed for assessment. The procedure should determine the scope of the missing data, the cause and the consequence for the ongoing work.
How do you set the no-data alarm time?
Base it on actual cadence, the number of tolerated misses and the normal transmission margin. Then shorten or lengthen it according to channel criticality and batching method. Test it with a controlled interruption. One value for the entire project usually creates either noise on slow channels or a late alarm on critical ones.
Is a device heartbeat enough instead of NO_DATA?
Not always. A heartbeat confirms that some part of the device or communications is working. It does not prove that a specific channel is producing valid measurements. The logger may respond while one input is dead, or the measurement frames may be rejected. The best model combines device status with checks of the freshness of the actual data.
Should the alarm disappear after history is backfilled?
The current state may return to OK after fresh data arrives, but the alarm history and the period of lost observability should remain. Backfill completes historical data, but it does not reverse the lack of information at the moment of the event. After the return, you need to check sequence, duplicates, possible threshold breaches and whether the procedure worked.
Should planned service disable the alarm?
It may justify temporary muting if the owner has approved the window and there is alternative control. The mute should have a deadline, a reason and a person. An indefinite disablement often remains after service. After the end of the window, the rule should protect the channel again and the team should confirm that valid data has returned. A mandatory post-service test should check both the measurement and the notification.
Who should receive the no-data alarm?
The first recipient is usually the person able to assess the impact of the missing data and start diagnostics, not automatically the whole management team. For a critical channel, the procedure may also inform the person responsible for the works. The list depends on the TARP, the time of day and the class of data. The system cannot replace agreed responsibility or on-call duty.
Does NO_DATA prevent all silent failures?
No. It detects the absence of new data, but it will not detect a sensor that regularly sends a wrong, frozen or miscalibrated value if there are no additional checks. You need variability tests, comparison with other channels, reference checks, calibration reports and an engineer's assessment. NO_DATA is one layer of protection.
Sources and further reading
- USACE EM 1110-2-1908: Instrumentation of Embankment Dams and Levees - planning the frequency, review and maintenance of instrumentation.
- FERC: Dam Safety Surveillance and Monitoring - surveillance, monitoring and rapid data assessment.
- NIST NCCoE SP 1800-7B - continuity, availability and trustworthiness of sensor systems.
- ISO 18674-1:2015 - general principles of geotechnical monitoring.
- Measurement data SLA: seven metrics - completeness, freshness and gaps.
- Alarm thresholds in structural monitoring - broader context for alarm design.
What next
Want to check whether your green dashboards really have fresh data? Book a review of cadence, gaps and NO_DATA rules. We can start with one device and one week of history.