This page is for real operators and on-site maintenance. Stabilize one camera on the same LAN before expanding to more cameras, remote sites, and automated reports.

Daily operator check

1. Confirm the App shows READY and critical cameras are online.
2. Review suspicious and critical incidents and snapshots since the previous shift.
3. Confirm Telegram or your selected notification channel receives a test incident.
4. Check that cameras have not been moved, blocked, defocused, or blinded by backlight.

Why do remote cameras often fail?

Public RTSP is often blocked by an ISP, CGNAT, firewall, or the camera itself, and it is unsafe. Prefer an on-site computer or edge agent, a site-to-site VPN, or a managed VPN so Sentinel connects through a private IP. Never expose RTSP directly to the internet.

Scheduled reports

Create a daily briefing, after-hours check, or hourly review. Scheduled jobs observe and report only; they never take a physical action. Create them through Agent/chat, or ask a technical operator to configure the API.

Event and snapshot retention

Event logs stay local; critical snapshots are retained for 14 days by default. Adjust this for privacy, customer notice, and retention policy. When evidence is needed, filter and export the relevant incident rather than sharing a bulk video archive.

Fast troubleshooting order

1. No video: check camera power, the local network, and RTSP URL, then see the RTSP guide.
2. Video but no analysis: confirm the inference engine Test Connection is OK and that the camera is not in standby.
3. No alert: confirm the incident actually reached suspicious/critical, then check alert policy, token, chat ID, or webhook signature.
4. Too many false alarms: make the mission specific about area, behavior, and exceptions; do not write only “anything unusual.”