Air Quality Monitoring Alerts: From Thresholds to Investigation and Response

An air-quality alert is useful only if someone can understand why it fired, decide whether the measurement is credible and know what to do next. A threshold number alone does not provide that. The rule also needs a time basis, persistence logic, data-validity checks, recipients and a defined response.

That matters because continuous monitoring can generate short-lived peaks, changing background conditions, maintenance-related anomalies and repeated notifications as well as genuine environmental events. The objective is not to suppress real changes. It is to prevent every fluctuation from becoming an unsupported conclusion or a stream of messages that no longer helps the team act.

An alert rule is more than a threshold

For operational monitoring, it helps to separate three ideas. A condition is the logic being watched. An alert is the event created when that logic is met. A notification is the message sent to a person or system. If those elements are treated as the same thing, projects often end up configuring a concentration value first and deciding what it means only after notifications start arriving.

A useful alert rule should therefore state what condition matters, what time basis is used for evaluation, whether the condition must persist, what data-quality state is acceptable, who receives the notification and what the first review step is. Each setting changes the operational meaning of the alert.

Design thresholds, time basis and persistence together

A threshold should never be interpreted without its evaluation time basis. The same numerical threshold can describe a very different event depending on whether it is evaluated on a current value, a short interval aggregate, a rolling average, a block average or another defined time representation. For example, a one-minute value, a 15-minute average, a one-hour average and a daily average represent different temporal evidence. The evaluation period should match the monitoring question. Short and longer time representations describe different types of event, so the rule should be based on the event the project wants to detect rather than simply on the fastest value the platform can display.

Persistence adds a second time dimension. A rule can fire on the first qualifying evaluation, after two or more consecutive qualifying periods, or after a condition has remained active for a defined duration. Requiring persistence can reduce notifications caused by isolated spikes, but it can also delay review. The appropriate logic depends on the monitoring objective, the measurement method and the consequence of missing or delaying an event.

Construction-dust guidance provides a useful example of why the complete alert rule matters. In UK professional guidance from IAQM, Site Action Levels are defined together with an averaging period, while site-specific protocols can also require qualifying conditions over consecutive shorter periods. These values and rules are project- and jurisdiction-specific; the transferable principle is that threshold, time basis, persistence and measurement capability need to be designed together. A 2025 IAQM position statement also emphasises that the monitoring system used for elevated PM10 episodes must be demonstrated as fit for purpose.

Reduce notification noise before it reaches people

Alert fatigue is usually a configuration problem before it is a messaging problem. If every short fluctuation creates a new email or text, important events become harder to distinguish from routine noise. Several controls can make notifications more useful without hiding the underlying measurements:

• Use persistence or confirmation logic where the monitoring objective justifies it.
• Define when an active alert clears and becomes eligible to fire again.
• Set a sensible re-notification interval for an event that remains active.
• Route network or data-quality conditions separately from environmental concentration alerts.
• Send each alert only to roles that have a reason to review or act.

The notification itself should carry enough context to be useful without requiring the recipient to reconstruct the rule. At minimum, it should identify the monitoring location, pollutant or parameter, observed value, unit, evaluation time basis, timestamp, configured threshold or condition, persistence or duration status, and a direct route to the relevant monitoring view. If the recipient cannot tell why the alert fired, the message is incomplete.

Verify the measurement before escalation

An operational alert is a prompt to review the evidence, not a declaration that an environmental problem has been proven. The first escalation step should therefore confirm that the measurement and the rule are behaving as expected.

• Device and channel status, including whether the monitor is online and behaving normally.
• Timestamp, time zone and evaluation-period alignment, especially when comparing several data sources.
• Data completeness and whether the evaluated value or aggregate contains enough valid observations for the intended use.
• Recent maintenance, calibration or quality flags, plus unusual jumps, repeated identical values or other suspicious patterns.
• Nearby monitoring points when the network design makes spatial comparison meaningful.

Frequent data review and automated screening for range, rate of change, repeated values and spatial consistency can help identify questionable data. Automated QC should support, not replace, informed review because genuine environmental events can sometimes resemble data anomalies and subtle technical problems may escape simple rules.

Add context without turning it into source attribution

Once the measurement has passed the first checks, the next question is what was happening around the event. Three context layers are especially useful: meteorology, nearby nodes and site activity.

• Meteorology: wind direction and speed can show whether transport from a particular area is plausible at that time; temperature, humidity or rainfall may also matter depending on the pollutant and measurement method.
• Nearby nodes: spatial comparison can show whether a change is local, shared across the network or inconsistent with the expected pattern, while recognising that different locations may measure genuinely different conditions.
• Site activity: demolition, material handling, traffic, process changes, maintenance, complaints or field observations can help reconstruct the event timeline.

These checks strengthen or weaken an investigation hypothesis; they do not prove a source automatically. A wind direction, a nearby activity and a concentration peak can be mutually consistent without establishing causation. The purpose of the context review is to decide what deserves further investigation and what response is justified by the available evidence.

Define the recipient and response before enabling the alert

An alert has little operational value if it reaches people who cannot interpret it or act on it. The recipient should be chosen from the response workflow, not from a generic distribution list. Depending on the project, that may be an HSE/EHS lead, environmental manager, construction site manager, plant operator, municipal environmental team or consultant. Technical network alerts may need a different owner from environmental-condition alerts, while broader stakeholder reporting and transparency require a separate communication workflow.

A simple response sequence is:

1. Acknowledge the alert and confirm that the correct person has ownership.
2. Verify the measurement, data status and alert logic.
3. Add the relevant meteorological, spatial and operational context.
4. Investigate the event according to the project procedure.
5. Apply only the response justified by the evidence and predefined plan.
6. Record what was reviewed, what was concluded and what action was taken.

The response may range from observation and field inspection to additional dust suppression, adjustment of a site activity, technical maintenance or escalation to another responsible role. The alert should not invent the action; the project plan should define the available responses and who has authority to use them.

Use alert history to improve the monitoring programme

Alert history is most useful when it is treated as feedback on the alert design itself. A periodic review can show which rules generate repeated low-value notifications, which alerts led to real investigation or action, whether events recur under similar conditions and whether recipients are responding as intended.

• Which rules generate repeated low-value notifications?
• Which alerts led to a real investigation, field check or operational action?
• Are data-quality alerts being confused with environmental-condition alerts?
• Do notifications cluster by project phase, time of day or meteorological condition?
• Are acknowledgement or response delays occurring because the wrong role receives the message?
• Did a documented change in threshold, time basis or persistence improve alert usefulness?

Rules should not be tuned simply to reduce the number of inconvenient alerts. Any change should have a documented rationale tied to the monitoring objective, evidence from the alert history and, where applicable, permit, planning or authority requirements.

Operational project alerts are not regulatory alert thresholds

The word alert also has a formal regulatory meaning. Directive (EU) 2024/2881 defines alert thresholds for specific ambient-air pollutants within the EU air-quality framework, with specified averaging periods, persistence conditions, representative-area requirements and public-information or short-term action obligations.

A project-specific operational alert from a continuous monitoring network is a different tool. It may be set at a different level, use a different evaluation time basis or serve a different purpose such as dust-control review, investigation of a local event or network supervision. Meeting a project alert condition does not automatically establish a statutory exceedance, regulatory non-compliance or source attribution.

Where an authority, permit, planning condition or approved monitoring plan specifies a trigger, the applicable measurement method, averaging or evaluation period, data-quality requirements and authority or permit procedure should govern the project rule. Otherwise, the alert should be designed from the monitoring objective and documented as an operational trigger rather than presented as a regulatory threshold.

Where Aernode fits

Aernode Reporting Tools can support project-specific alert workflows through automated notifications based on pollutant thresholds, data conditions or network-operational events. Alert logic, recipients and distribution workflows can be configured according to the project and selected reporting environment. Available alert logic depends on the selected project and Reporting Tools configuration.

For this type of use, the important configuration question is not how many alerts the system can send. It is whether each alert is tied to a meaningful rule, enough measurement context for review and a response process that the project team has already agreed. Aernode alerts support operational monitoring; they do not by themselves turn a sensor event into a regulatory determination or automatic source attribution.

A useful alert should lead to a defined review

Before an alert goes live, the project should be able to answer:

• What is the purpose of the alert?
• Which parameter or data condition is being watched?
• What threshold applies?
• What evaluation time basis is used?
• Is persistence required?
• What data-validity conditions must be met?
• Who receives the notification?
• What is the first review step?
• When is escalation justified?
• How will the event and response be recorded and later reviewed?

If those answers are clear, an air-quality alert becomes part of an operational decision process. If they are not, the system may still send notifications, but the team will be forced to decide what each notification means after it arrives. The design goal is therefore straightforward: configure the alert and the response workflow together.

Technical References

1. U.S. Environmental Protection Agency. Enhanced Air Sensor Guidebook (2022). U.S. technical guidance used for transferable principles on aggregation, QA/QC and air-sensor data review.

2. Institute of Air Quality Management (IAQM). Guidance on Air Quality Monitoring in the Vicinity of Demolition and Construction Sites (2018 v1.1). UK professional guidance used as an operational example of PM10 Site Action Levels, time basis and site-specific alert protocols.

3. Institute of Air Quality Management (IAQM). Use of Low-Cost Sensor Systems for PM10 in the Vicinity of Demolition and Construction Sites and Considerations of PAS 4023:2023 (2025). UK professional position statement used for the fit-for-purpose measurement safeguard at elevated PM10 concentrations.

4. European Parliament and Council. Directive (EU) 2024/2881 on ambient air quality and cleaner air for Europe (recast). EU legal reference used only to distinguish formal regulatory alert thresholds from project-specific operational notifications.