See What Is Changing. Know What Needs Attention.
Siteplore turns connected operational data into current-state visibility, historical context and configurable alerts — helping teams recognize meaningful changes earlier and investigate them with the information available around the event.
The problem is not always missing data. Sometimes the problem is knowing which change matters.
Connected systems can produce thousands of measurements. Without context, thresholds and prioritization, operators and engineers may still discover important changes too late — or receive so many alerts that meaningful events are lost in the noise.
Conditions Change Between Rounds
Equipment or process conditions may change before the next manual inspection.
Too Much Raw Data
Continuous measurements are useful only when teams can identify which changes deserve attention.
Static Thresholds Without Context
A threshold can create noise if load, operating state or process context is ignored.
Alarm Flood
Too many similar notifications can make prioritization difficult and reduce user attention.
No Historical Evidence
When an event occurs, teams need the trend before and during the event to investigate it.
Alert Without Workflow
Notifications create limited value if no one knows who should review them or what evidence to check next.
Operational awareness at the speed appropriate to the monitoring use case.
Siteplore monitoring is intended for operational awareness, engineering visibility and event detection. Required update intervals should be engineered around the physical process, sensor capability, network and operational decision.
Live Monitoring View
Present the latest available measurements and asset status according to the configured update path.
Configurable Alert Logic
Evaluate selected measurements against defined monitoring conditions at configured intervals.
Historical Before & After
Combine the event with surrounding time-series history for investigation.
A useful alert is a monitoring workflow, not simply a threshold.
Field Condition
Sensor, meter or equipment produces operational data.
Monitoring Logic
Evaluate selected conditions, thresholds or state logic.
Alert / Event
Surface the condition through the configured alert workflow.
Trend & Context
Review related measurements, history and operational context.
Operational Action
Inspect, verify, prioritize or escalate appropriately.
Alert design can move beyond one value crossing one threshold.
The appropriate logic depends on the measurement, process behavior and consequences of missing or over-triggering an event.
High / Low Threshold
Trigger an event when a selected metric crosses an agreed monitoring limit.
Persistence
Require the condition to persist for a defined period before creating an alert.
Operating Condition
Interpret a measurement differently depending on running or process state where available.
Rate or Trend Change
Monitor selected changes over time where a developing trend is more important than one absolute value.
Missing Data / Device Health
Detect when an expected data stream stops reporting or becomes unavailable.
Outlier / Forecast Context
Where supported, analytics can help evaluate unusual behavior beyond fixed thresholds.
More alerts do not automatically create better monitoring.
A useful alert should represent a meaningful condition, reach the right audience and provide enough context for the next decision.
Actionable
An alert should correspond to a condition that deserves a defined review or response.
Prioritized
Different monitoring events should not automatically be treated as equally important.
Contextual
Asset identity, operating state and related trends can make an event easier to interpret.
Stable
Persistence, hysteresis or suitable logic can reduce unnecessary alert chatter.
Owned
Someone should know who reviews the event and what should happen next.
Reviewable
Alert performance should be reviewed and adjusted as operational experience grows.
Move from visualization toward investigation and response.
Siteplore can use capabilities available within the deployed Grafana Cloud environment to support monitoring, alerting and analytical workflows. Exact availability depends on the customer stack, plan, datasource and configuration.
Grafana Alerting
Evaluate configured conditions and surface monitoring events from supported data sources.
Investigations
Support structured investigation of relevant monitoring changes where the capability is available.
IRM
Incident-response capabilities can support broader event handling where appropriate to the deployment.
Automations & Watchers
Available workflow capabilities can support selected monitoring and follow-up processes where configured.
Outlier Detection
Outlier-detection capabilities can help highlight unusual behavior in suitable monitored metrics.
Metric Forecasts
Forecasts can provide additional context for suitable time-series metrics, anomaly-detection support or capacity-planning use cases.
AI Assistant
Available AI-assisted capabilities can help users search, explore and investigate operational information.
Search
Search capabilities can help users navigate monitoring resources and relevant operational information.
SLO Capabilities
Where applicable, service-level concepts can support monitoring of selected availability objectives.
These are platform capabilities that may be used where supported by the relevant Grafana Cloud subscription and project configuration. They are not automatically included in every Siteplore package.
The alert should be the beginning of the investigation — not the conclusion.
When Siteplore highlights a condition, users should still evaluate the quality of the measurement, asset operating state, surrounding trends and relevant engineering context.
Real-time awareness starts with the right field information.
RekaSense
Bring compatible environmental, water, agriculture, process and remote sensor data into Siteplore.
Explore RekaSense →PowerWatch
Monitor compatible electrical and energy data for operational awareness and trend context.
Explore PowerWatch →MachineGuard
Add condition-monitoring and early-warning visibility for selected rotating equipment.
Explore MachineGuard →Use alerts where earlier awareness can improve the next decision.
Developing Equipment Change
Highlight a configured change in selected condition measurements for engineering review.
→ Alert Logic
→ Trend Investigation
Unexpected Demand
Identify selected electrical-demand conditions requiring operational review.
→ Demand Event
→ Energy Context
Environmental Threshold
Surface selected environmental measurements outside an agreed monitoring range.
→ Monitoring Rule
→ Review
Water-Quality Change
Highlight changes in suitable online water-quality measurements for verification.
→ Event
→ Verify & Investigate
Data Loss
Detect when a remote monitoring point stops reporting according to the expected pattern.
→ Missing Data
→ Connectivity Review
Abnormal Operating Context
Combine selected process, equipment or utility measurements to support investigation.
→ Event Context
→ Engineering Decision
Define what should trigger attention, who should see it and what happens next.
Exact deliverables depend on the data available, monitoring objective, customer workflow and selected Siteplore engagement.
Monitoring Requirement Definition
Define the condition that should become visible or trigger review.
Dashboard Status Views
Current-state and historical monitoring views appropriate to the project scope.
Alert Logic
Configured monitoring conditions where technically justified.
Severity / Priority Structure
Appropriate event classification where included in the design.
Notification Workflow
Defined notification path using supported channels where included in scope.
Historical Investigation Views
Relevant trends for reviewing the condition around an event.
Customer Access Configuration
Monitoring access aligned with the selected customer environment.
Training & Alert Review
Knowledge transfer on how to interpret and respond to configured monitoring events.
Start with reliable conditions. Add sophistication only when it improves signal quality.
Monitor
Establish reliable current-state and historical data.
Threshold
Add meaningful high / low monitoring conditions.
Context
Add persistence, operating state and related signals.
Analyze
Use investigations, trends and suitable analytics.
Improve
Review false positives, missed conditions and response quality.
Monitoring alerts are not the same as safety trips, interlocks or protection.
Siteplore alerts support awareness and investigation. They should not be treated as a substitute for deterministic control, protective relays, machinery protection, SIS, ESD or other safety-critical systems.
| Function | Siteplore Monitoring | Important Boundary |
|---|---|---|
| Current-state dashboard | Yes | Update rate depends on configured architecture |
| Historical trend | Yes | Depends on data availability |
| Threshold monitoring | Yes | Condition must be engineered appropriately |
| Missing-data event | Where configured | Requires expected reporting behavior |
| Outlier / forecast context | Potentially | Depends on data and available Grafana capability |
| AI-assisted investigation | Where available | Not an automatic engineering conclusion |
| Hard real-time control | No | Dedicated deterministic control system required |
| Automatic safety shutdown | No | Dedicated safety system required |
| Electrical protection trip | No | Protective relay / device remains responsible |
| Machinery protection trip | No | Dedicated machinery protection remains responsible |
| Guaranteed anomaly detection | No | Analytical performance requires validation |
Define the condition first. Configure the notification second.
Site Assessment
For organizations that need to determine which conditions deserve continuous monitoring.
- Operational-problem review
- Monitoring-point definition
- Existing instrumentation review
- Alert-condition discussion
- Recommended architecture
90-Day Paid Pilot
Test a focused monitoring and alert use case before expanding across the site.
- Selected operational metrics
- Dashboard monitoring
- Configured alert logic
- Event review
- Pilot findings & improvement recommendation
Siteplore Deployment
For organizations requiring monitoring and event visibility across multiple assets or domains.
- Integrated monitoring architecture
- Multiple dashboards
- Alert structure
- Customer monitoring access
- Training & support scope
Real-Time Monitoring & Alerts FAQ
Is Siteplore monitoring truly real-time?
Siteplore provides operational current-state monitoring, but the actual latency depends on sensor sampling, edge acquisition, communication, cloud ingestion, query frequency and dashboard or alert evaluation intervals. It should not be interpreted as a deterministic hard real-time control system.
How often can dashboard data update?
The appropriate update interval depends on the use case, sensor, network, data volume and configured cloud architecture. Faster refresh is not automatically better if the physical process does not require it.
Can Siteplore send alarms?
Siteplore can use configured Grafana Cloud alerting capabilities to identify selected monitoring conditions where supported and included in project scope.
Can alerts have different priorities?
Event classification and priority can be designed where appropriate, but the structure should reflect the operational consequence and intended response workflow.
Can Siteplore detect when a sensor stops reporting?
Missing-data monitoring can be configured where the system knows the expected reporting pattern for the data source.
Can alerts depend on whether a machine is running?
Potentially yes where reliable operating-state information is available. State-aware logic can reduce inappropriate alerts when a machine is stopped or operating under a different condition.
Can Siteplore detect anomalies without fixed thresholds?
Grafana Cloud outlier-detection or other analytical capabilities can potentially provide additional context where suitable data and configuration exist. Their performance should be validated against the actual use case.
Can Siteplore forecast a metric before it becomes abnormal?
Metric Forecast capabilities can be evaluated for suitable time-series data where available within the deployed Grafana Cloud stack. Forecasting supports analysis; it does not guarantee future equipment or process behavior.
Can AI investigate an alert automatically?
AI-assisted and investigation capabilities may support exploration and interpretation where available, but an AI result should not automatically be treated as a verified engineering diagnosis.
Can Siteplore automatically stop equipment after an alert?
Not as a standard Siteplore monitoring function. Automatic control or shutdown requires dedicated control, interlock and safety engineering appropriate to the application.
Is a Siteplore alert the same as a DCS alarm?
Not necessarily. Siteplore is primarily a cloud monitoring and analytics layer. DCS, PLC or SCADA systems remain appropriate for plant-control and operational alarm functions where required by the process.
Is a Siteplore alert a machinery-protection alarm?
No. MachineGuard and Siteplore can provide condition-monitoring and early-warning visibility, but dedicated machinery protection systems remain responsible for protection functions.
Can the customer see alerts from a Grafana Cloud account?
Customer access can be configured within the Grafana Cloud monitoring environment assigned to the organization, according to user role and deployment scope.
Can one monitoring environment cover multiple sites?
Multi-site monitoring can be designed where the customer architecture, data isolation, connectivity and access model support it.
How should we decide what deserves an alert?
Start with the operational consequence. Define what change matters, what evidence would confirm it, who needs to know, and what action should follow. Only then define the alert logic and notification path.
The goal is not to generate more alarms. It is to surface the changes worth investigating.
Rekacipta can help define meaningful monitoring conditions, connect the required measurements, configure Siteplore dashboards and alerts, and build an investigation workflow that gives operators and engineers useful context when something changes.