Surveillance system SLA: how integrators set and meet one

A surveillance system SLA is the written commitment an integrator makes about how fast it responds to, and restores, each kind of camera failure. A useful one names the failure classes, sets a response and restore target for each, says which hours count, and says how both sides will know whether the target was met.

Most camera and CCTV service agreements stop well short of that. They say “four-hour response” and leave it there. The number is fine. What breaks it is the event that starts the clock. If the integrator learns about a dead camera when the customer calls, the response time measures how long the customer took to notice, plus how long the dispatcher took to read the email. The integrator can meet that SLA every month and still have cameras dark for weeks.

Where the clock should start

The clock in a surveillance system SLA should start when the failure is detected, not when someone reports it. That moves three steps into the integrator’s control:

1. Detection. Something has to watch every camera continuously and notice that it went offline, went black, froze, lost its SD card, or was tampered with.
2. Classification. The alert has to say what kind of failure it is and how serious it is, so nobody triages it by hand at 2 a.m.
3. Delivery. The alert has to become a ticket in the system the service team already works from, with the priority already set.

When those three steps happen without a person in the loop, response time measures the integrator’s team. That is the part of the service the customer is paying for.

Define severities by customer impact

A severity is a class of promise. Write four, define each by what the customer loses, and list real conditions under each so nobody argues about it later. This is the classification MentatNOC applies out of the box. An integrator can use it as written or as a starting point.

Severity	What the customer loses	Example camera conditions
Critical	A whole site’s coverage at once	Site connection lost, so every camera there is unreachable at the same time
High	Several cameras, or recording on one	Three or more cameras offline, SD card failed, SD card at end of life, tamper event
Medium	One or two cameras, or a degraded image	One or two cameras offline, image black, image frozen, SD card missing, over temperature
Low	Nothing yet, but a failure is scheduled	Certificate expiring, insecure service enabled, clock drift, SD card wear high

Two notes on the table. SD card wear is reported by Axis cameras. Hanwha cameras do not report wear, so a Hanwha card shows up as failed or missing rather than worn. And “SD card missing” only applies to a camera that had a card before, so a camera designed without local storage does not open a ticket every day.

The low tier earns its place. An expiring certificate is an outage with a date on it. Catching it at low severity with weeks of lead time turns it into a planned change instead of a critical ticket on the morning it expires.

Set the targets yourself

Response and restore targets are the integrator’s business decision. They depend on staffing, coverage hours, geography, and what the customer is willing to pay for. A hospital and a warehouse should not get the same SLA, and a monitoring product should not pick the numbers for either.

What the monitoring side should do is make the targets easy to apply. The pattern that works:

• Each severity maps to a priority in the integrator’s ticketing system.
• The ticketing system applies the SLA attached to that priority, with its own business hours, holidays, and escalation rules.
• Contract-specific terms, such as a customer that bought around-the-clock response on critical, live in the ticketing system next to the contract, where the service desk already looks.

That keeps the SLA in one place. Change a target in the ticketing system and every camera alert after that is measured against the new target, with nothing to change on the monitoring side.

Get alerts into the ticketing system

There are two practical ways a camera alert becomes a ticket.

Email. Nearly every ticketing system can turn inbound email into a ticket. Email is the fastest way to start, and it works with systems that have no integration at all. The tradeoff is that email only opens tickets. It cannot update or close one when the camera recovers.

Direct API. A direct connection creates the ticket with its fields already set: company, priority, issue type, queue. It keeps one ticket per open problem and updates or closes that ticket when the condition clears. MentatNOC connects natively to Autotask and ServiceNow, and sends a webhook to other systems.

Whichever path an integrator uses, check three things before the SLA goes live.

1. One ticket per problem. A camera that drops in and out should not open twenty tickets. Duplicates also wreck SLA reporting, because the quickest-closed duplicate looks like a fast response.
2. The ticket names the device and the site. A ticket that says “camera offline” with no name sends a technician to look it up before they can act, and the lookup time counts against the SLA.
3. Site-level failures are separated from camera failures. If a site’s connection drops, forty camera-offline tickets is the wrong result. One critical ticket for the site is right, and the camera alerts should hold until the site is back.

Write the measurement into the contract

Agree up front on how the SLA will be measured, or the monthly review turns into an argument about clocks.

• Which timestamps count. Ticket created, first response, and restored. Use the ticketing system’s timestamps so neither side disputes them.
• What is excluded. Planned maintenance windows, failures caused by the customer’s network or power, and cameras past end of vendor support that the customer has not approved for replacement.
• What is in scope. Device conditions the monitoring watches are in. Physical damage, vandalism, and aim drift are found on site visits and usually run on a separate schedule.
• How results are reported. Monthly or quarterly, next to camera uptime by site. The report is where the integrator shows the SLA was met, and where the customer sees what the service fee bought.

An SLA on camera health only means something if camera health monitoring is in the contract. Write it in as part of the service agreement and bundle it with the monitoring services the integrator already sells, such as intrusion or alarm monitoring. Customers already understand paying for alarm monitoring, and alarm monitoring for the cameras that were already installed fits the same contract, the same queue, and the same response targets.

The failure modes behind most camera tickets, and what each usually means on site, are in why security cameras go offline.

Doing this across 500 cameras

At one site, a technician who knows the building can keep a surveillance system SLA from memory. Across a few hundred cameras and a few dozen customers, the SLA depends on alerts arriving classified and landing in the right queue without anyone reading them first.

MentatNOC is a white-label managed services toolkit for security integrators. It classifies each alert by severity, issue type, device, and site, and opens a ticket in the integrator’s own ticketing system, where the integrator’s own SLA applies to each priority. Each ticket says whether the site connection was up, and a site-wide connection loss opens one critical ticket instead of a flood of camera tickets. Dispatch knows what failed before the truck leaves the shop, the tech brings the right part when the alert calls for one, and the clock stops on the first trip.

Integrators add it to service contracts and bundle it with the monitoring they already sell, as alarm monitoring for the cameras they already installed. Catching an outage before the customer does, and calling first, is the easiest SLA conversation an integrator will have. It monitors device health, not video. How alerts and ticketing fit into the platform is on the platform overview, and the live demo shows the alert feed a NOC works from.