---
title: "Event Processing"
source: /gcxone/platform-fundamentals/event-processing
locale: en
updated: 2026-09-13
---
## **What Event Processing Does**

Understanding how GCXONE processes events is essential for operators and administrators. Every alarm on the dashboard has passed through a structured processing pipeline — from the moment a camera detects movement to the point an operator takes action.

GCXONE classifies, filters, and routes every incoming event automatically, ensuring that only genuine security threats reach the operator queue.

## **Why It Matters**

Without structured event processing, operators would be flooded with raw unfiltered events — making it impossible to prioritize real threats. The processing pipeline ensures every event is classified, filtered, and routed to the right destination before any human sees it.

## **How It Works**

**Step 1 — Detection** A camera or sensor detects an activity and sends a signal to the GCXONE platform via the Proxy Layer.

**Step 2 — Ingestion** The platform receives the raw event and logs it with a timestamp, device ID, site, and customer reference.

**Step 3 — AI Analysis** The event is passed through the NOVA99x AI engine, which classifies it as a Real Alarm, False Alarm, or Tech. Alarm.

**Step 4 — Routing**:

- Real Alarms are pushed to the operator queue in Talos for action.
- False Alarms are filtered out and stored for reporting and analytics.
- Tech. Alarms trigger automated notifications and can initiate workflows such as calling a technician or sending an SMS or email.

**Step 5 — Resolution** The operator reviews, processes, and closes the event. All actions are logged in the Audit Logs.

## **Key Capabilities**

**Event Types** GCXONE classifies every incoming event into one of three categories:

- **Real Alarm** — A genuine security event requiring operator attention, such as motion detection, line crossing, or intrusion.
- **False Alarm** — An event triggered by non-threatening activity such as animals, weather, or lighting changes. Filtered out by NOVA99x to reduce operator workload.
- **Tech. Alarm** — A system-generated event triggered by HealthCheck, such as a camera going offline, black screen, obstruction detection, or low light conditions.

**Event States** An alarm moves through the following states during its lifecycle:

- **New** — The alarm has just been triggered and is awaiting action.
- **In Progress** — An operator or workflow is actively working the alarm.
- **Closed** — The alarm has been resolved and closed out.

AI Filtering — NOVA99x Before any event reaches an operator, it passes through NOVA99x — GCXONE's AI filtering engine. NOVA99x analyzes each event using behavioral analysis and image recognition to determine whether it represents a real threat, filtering out false alarms before they reach the operator queue.

>   For full details on NOVA99x, refer to the [NOVA99x](/gcxone/features/nova99x) page.

## **Real-World Use Cases**

- A camera detects a shadow moving across the frame — NOVA99x classifies it as a False Alarm and filters it out before it reaches any operator.
- A camera goes offline at 03:00 — GCXONE classifies it as a Tech. Alarm and automatically sends an SMS to the on-call technician.
- An intrusion alarm triggers — it passes through NOVA99x, is classified as a Real Alarm, and is pushed to the Talos operator queue with full video context within seconds.

## **Best Practices**

- Monitor the ratio of Real vs. False Alarms regularly — an unusually high Real Alarm rate may indicate NOVA99x needs reconfiguration.
- Never ignore Tech. Alarms — a camera going offline means a blind spot in your coverage.
- Always ensure every event is closed with a documented outcome to maintain a clean Audit Logs history.

## **Additional Details**

### Troubleshooting — Diagnosing Alarm Count Mismatch

If the number of alarms reported in GCXONE does not match the device's internal logs, follow these steps to identify the source of the discrepancy:

**Step 1:** Compare the exact time window and alarm count between the device logs and GCXONE's Video Search.

![](/api/media/file/efc244645bd24ac7503ab266f58b9f93af9f4983-1918x981.png)

**Step 2:** Install the vendor-provided test client and configure it using the device's connection parameters (IP address and port).

**Step 3:** Run the test client and monitor the alarm flow directly from the device.

**Step 4:** Compare the test client results against the device log:

- **If counts match** — The issue is in the GCXONE implementation. Escalate to the development team.
- **If counts don't match** — The issue is with the device or vendor. Contact vendor support.