GC SurgeDocsAlarm Pipeline
5 min read

Alarm Pipeline

This page explains how alarms travel from your cameras to your operators — every step from camera trigger to operator review to performance logging. When a camera detects motion or triggers an event, it forwards the alarm to GC Surge using standard protocols — SMTP, FTP, or webhooks. No custom integration is required. Any camera or NVR that supports these standard forwarding methods works immediately. Covers: The Five Stages, Stage 1 — Camera Sends the Alarm, Stage 2 — GC Surge Receives and Processes.

The Five Stages

Stage 1 — Camera Sends the Alarm

When a camera detects motion or triggers an event, it forwards the alarm to GC Surge using standard protocols — SMTP, FTP, or webhooks. No custom integration is required. Any camera or NVR that supports these standard forwarding methods works immediately.

Stage 2 — GC Surge Receives and Processes

Every alarm is either accepted or blocked based on subscription status:

  • Accepted — subscription is active. The alarm is stored, metered, and made visible in Video Search.
  • Blocked — subscription is inactive. The alarm is logged but does not count toward billing and does not appear in any operational view.

Accepted alarms are normalized into a common format and enriched with site, camera, tenant, and source-mode context before moving to AI classification. GC Surge queues and retries transient failures to ensure no alarm is lost. Receipt time, source, and camera identity are preserved regardless of downstream delays.

Stage 3 — NOVA99x Classifies

NOVA99x analyzes each alarm and classifies it as real or false. Events classified as non-actionable are filtered — they do not appear in ZenMode or Video Search. All alarms — filtered and unfiltered count toward billing. See NOVA99x AI Filtering for activation steps and phased rollout guidance.

Stage 4 — Operator Handles in ZenMode

Alarms that pass classification appear in ZenMode, the operator's live monitoring screen. Operators see a real-time feed grouped by camera and site, review flagged alarms, and close them one at a time or in batches. Every action is timestamped and recorded automatically. See ZenMode Operator Monitoring in the Operations section for the full operator guide.

Stage 5 — Performance Captured

When a shift ends, every alarm handled, every decision made, and every second spent is logged automatically. Operators see their shift summary. Admins see the full picture across the team — live, from the dashboard.

Operators review the alarms that reach this stage in ZenMode, where they filter by detection type, alarm class, time range and tags and use the Heatmap, Mask and History Mask overlays. See the ZenMode — Operator Monitoring page for how the filters and overlays work.

How Alarms Are Grouped

GC Surge groups repeated events from the same camera into clusters using a configurable time window — 15 minutes by default. Admins can adjust this window per site. Camera clusters roll up into a site-level view when several cameras trigger together. The underlying event count stays visible so admins can judge volume without losing context.

Grouping reduces duplicate review work, makes supervision easier, and gives operators a clearer picture of whether they are handling one isolated trigger or a broader site incident.

How Each Connection Mode Arrives

All three connection modes deliver alarms through the same ingestion path. The source varies, but the downstream process is identical.

  • Mode 1 — Public IP: GC Surge pushes the forwarding credentials to the camera automatically — currently over SMTP for the supported brands. (FTP or webhook delivery is configured manually.) The camera then sends alarms directly to GC Surge.
  • Mode 2 — Private/VPN: cameras send alarms over the same path after the local agent completes field activation.
  • Mode 3 — Edge: the camera is configured on-site from the GDA mobile app (by scanning the site's QR code), after which it forwards alarms to GC Surge over the same path.

Alarm Protocols Supported

  • SMTP — the camera sends an alarm email with snapshot attachment to a GC Surge-provided address. Most widely supported method across camera brands.
  • FTP — the camera uploads alarm images to a GC Surge-provided FTP server.
  • Webhook / REST — the camera or NVR posts an alarm payload to a GC Surge endpoint via HTTP.

Alarm Payload Formats

Regardless of the protocol used, GC Surge accepts two alarm payload formats:

  • Snapshot image — the camera attaches a still image of the triggering event. This is the most common format and works across all supported camera brands.
  • Video clip — the camera attaches a short video recording of the event. GC Surge stores and displays the clip in ZenMode and Video Search in place of a static image, giving operators more context for their review decision.

The format is determined by what the camera sends — GC Surge does not require one over the other. If a camera is configured to send clips, clips are used. If it sends images, images are used. Both formats go through the same ingestion path and NOVA99x classification.

GC Surge