01
Metrics from the camera
Throughput, cycle time, dwell and idle detection derived from what the line is actually doing — no extra sensors, no operator data entry.
VRTLST Watch
Know what's happening the moment it happens
Most plants know their output at the end of the shift. Watch tells you during it — throughput, cycle time, dwell and micro-downtime measured from the camera rather than from a manual count, across every line and every site at once.
06:0010:0014:0018:0022:00
1,284units / hr
99.2%yield
4m 12sdowntime
What it does
Real-time monitoring
02
Alerts that find someone
Anomalies route to Slack, Teams, SMS, email or PagerDuty, with escalation when the first person does not acknowledge.
03
Searchable history
Ninety days of events you can filter by line, shift, product or fault, so a recurring stoppage is a query rather than a hunch.
How it works
From a camera to a decision
Continuous monitoring across every line and every site, with alerts that reach the right person in seconds.
- Live throughput, cycle time, dwell and idle detection
- Anomaly alerts to Slack, Teams, SMS or PagerDuty
- Ninety days of searchable event history
- Point it at the line
- Watch learns the normal cycle from a few hours of ordinary running.
- Set the baseline
- Confirm the expected rate and the tolerance you care about being told about.
- Route the alerts
- Map severity to channels and to the people actually on shift.
- Review the trend
- Compare lines, shifts and sites to find where the time is really going.
48 cameras monitored per site
90 days of searchable event history
5 alerting channels supported
Live no waiting for end of shift
Specifications
The technical detail
What your integrator will ask for on the first call.
- Metrics
- throughput · cycle time · dwell · idle · downtime
- Cameras per site
- 48 typical, no hard ceiling
- Alert channels
- Slack · Teams · SMS · email · PagerDuty
- History
- 90 days searchable, longer on request
- Export
- REST · MQTT · historian · CSV
- Granularity
- per line, per shift, per product
Getting started
How a Watch deployment goes
The same shape every time, whichever product you start with.
- Week 0
One hour of footage
Send us recorded video from a single line. We come back with what the model found in it — before anyone signs anything.
- Week 1–2
One line, one model
We stand up a pilot on the line that hurts most, using the cameras already mounted. Operators start correcting it on day one.
- Week 3–4
Wired into the line
The verdict moves from a dashboard to the PLC, the MES or the alerting channel your shift leads actually watch.
- Month 2
Second line, second site
The model and its thresholds travel. Command stages the rollout so a bad version never reaches more than one line.
- Ongoing
It gets better
Corrections accumulate, drift gets flagged, and new defect classes are a fine-tune rather than a project.
Do we need extra sensors?
No. Watch derives its metrics from the camera, which is the point — no PLC tags to expose, no counters to install, no operator data entry.
How does it know what normal looks like?
It learns the ordinary cycle from a few hours of running, then you confirm the expected rate and the tolerance you want to hear about.
Will we get alert fatigue?
That is the usual failure mode, so alerts are tiered and rate-limited by default, and escalation only fires when the first person does not acknowledge.
Can it feed our existing dashboards?
Yes. Watch writes to REST, MQTT and most historians, so the numbers can land in the BI tool your plant managers already open.
Keep exploring
The rest of the stack
Edge
The camera that thinks for itself
A sealed edge-AI device that runs the full VRTLST stack on-board. Single PoE cable in. Decisions out.
Explore Edge Command
Every camera, every site, one screen
The control plane for your whole visual estate — deployments, model versions, alerts, access and audit.
Explore Command Vision
One model that understands every camera you own
Detection, segmentation, tracking and classification from a single deployment — no per-camera retraining.
Explore Vision