Operations: checking cameras, activity log and support

A checking procedure for missing video or events, investigating incorrect settings and preparing a support request.

Updated 27 September 2026 · Application administrator / user · 8 min

Checks at the start of work

Make sure the correct user is selected and the required cameras are accessible. Open several operational sources, check that the video is current and review the log’s time period. Look at the queue of unreviewed events.

Check processing status and the time of the last result where these indicators are available. Do not treat the absence of new violations as sufficient evidence that analytics are healthy.

Shared dashboard, illustrated in BOX 5.0: camera totals and incident filters. The current selection includes no cameras and shows zero incidents; it is not a system-wide result.

If there is no video

Determine the scope: one camera, a site or all sources. Check camera status, connection parameters, permissions and source availability. Compare the current time with the last available frame.

If the problem started after editing, compare it with changes to the address, source password, resolution or site. Restore a setting to a known working value only within the accepted maintenance procedure.

BOX 3.2: Camera performance shows separate timelines for video acquisition and inference. The grey Disabled intervals in this example are not evidence of healthy continuous processing. Localized reference view; captured settings and values are preserved.

If video is available but there are no events

Check that processing is enabled, the assigned preset or scenario version, categories and thresholds. Then check zones, schedule, and event generation and sending rules. Check filters and access scope in the log.

For an LLM, separately check the run, response retrieval and response processing. Visible model text alongside an error may indicate a schema or directory problem rather than an unavailable LLM.

BOX 3.2: the Detectors tab before a preset has been selected. Add a preset, then verify its enabled categories; the empty form does not demonstrate active detection.

Activity log and incorrect settings

In the available activity log, set the period and user, then find changes made before the problem began. Correlate the record with the time of changes to the camera, role, rule or scenario version.

Record which value changed and what began happening. Do not change several independent parameters at once: it will be difficult to determine which action restored operation.

Shared action log, illustrated in BOX 5.0: filter by period, login, service and action, then display the records or download CSV.

Shared action log, illustrated in BOX 5.0: timestamps, services and recorded actions. This crop excludes the account and IP columns; log entries describe past actions, not current service health.

What to provide to the administrator or support

Prepare a brief description: expected result, actual behavior and steps to reproduce. Include the BOX version, time with time zone, site, camera or event ID, user role and last known change.

Attach an available screenshot and the error text without passwords, tokens or stream addresses containing credentials. For a scenario, include the version and run ID; for an LLM, include the prompt type and failure stage. State whether one source or the entire system is affected.

Shared Report error form, illustrated in BOX 3.2: describe the symptom and attach an appropriate file. The deployment URL is an example; submitting a report was not part of this illustration. Localized reference view; captured settings and values are preserved.

Use the documentation and configuration supplied for your installed release. Environment addresses and access credentials are provided privately with the delivery.