Skip to main content

​
Overview

When you check a Job, you get detailed statistics about its performance. This guide explains what each metric means and how to use them.

​
Job Response Fields

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "running",
  "job_type": "live-monitor",
  "created_at": "2024-01-26T10:30:00Z",
  "stream_url": "https://youtube.com/watch?v=abc123",
  "details": {
    "checks_performed": 45,
    "triggers_fired": 3,
    "frames_skipped": 112,
    "condition": "Is there a traffic accident?",
    "interval_seconds": 30,
    "model": "gemini-2.5-flash",
    "auto_stopped": false,
    "reason": null,
    "elapsed_seconds": null
  }
}

​
Understanding the Details

​
checks_performed

Definition: Number of frames that were analyzed by the VLM Example: 45 checks means the VLM looked at 45 frames What affects it:
  • interval_seconds: More frequent checks = more checks
  • frames_skipped: Fewer skipped frames = more checks
  • Duration: Longer running = more checks
Formula: 
Estimated checks = (duration in seconds) / interval_seconds × (1 - skip_rate)
Use case: Know how many VLM API calls you made

​
triggers_fired

Definition: Number of times your condition was detected as true Example: 3 triggers means the condition matched 3 times Typical values:
  • 0: Condition never matched
  • 1-5: Occasional matches
  • 10+: Frequent matches
Use case: Understand how often your condition occurs

​
frames_skipped

Definition: Frames filtered out by motion detection pre-filter Example: 112 frames skipped means the pre-filter prevented 112 unnecessary VLM calls Skip rate calculation: 
Skip Rate = frames_skipped / (checks_performed + frames_skipped) × 100
          = 112 / (45 + 112) × 100
          = 71%
A 71% skip rate means the pre-filter saved you from 71% of potential VLM calls! What it means:
  • 70%+ skip rate: Static scene (good! saves money)
  • 30-70% skip rate: Moderate motion
  • Less than 30% skip rate: Lots of movement in scene
Use case: Understand your cost efficiency

​
condition & interval_seconds & model

These are configuration values, not performance metrics. They show what you configured the job with:
  • condition: The query that was watched for
  • interval_seconds: How often to check (30 seconds in this example)
  • model: Which VLM was used (gemini-2.5-flash in this example)

​
auto_stopped, reason, elapsed_seconds

These fields only appear if the job is stopped: auto_stopped: 
{
  "auto_stopped": true,
  "reason": "max_duration_reached",
  "elapsed_seconds": 600
}
Jobs stop after 10 minutes (600 seconds) to prevent runaway costs. Possible reasons:
  • max_duration_reached: Job hit the 10-minute limit
  • condition_triggered: Job stopped because condition matched (and you have that configured)
  • manually_stopped: User called DELETE to cancel

​
Calculating Your Costs

​
Cost Formula

Cost = (checks_performed) × (cost per API call)

​
Example

From the job above:
  • 45 VLM checks
  • Using gemini-2.5-flash: ~$0.00002 per call
  • Cost: 45 × 0.00002=∗∗0.00002 = **0.0009** (less than 1/10th of a cent!)

​
Cost Savings from Pre-filtering

Without pre-filter: 
Total frames = 45 + 112 = 157
Cost = 157 × $0.00002 = $0.00314
With pre-filter: 
VLM calls = 45
Cost = 45 × $0.00002 = $0.0009
Savings: 71% - That’s the power of the pre-filter!

​
Analyzing Job Performance

​
Example 1: Good Job (Rare Condition)

{
  "checks_performed": 120,
  "triggers_fired": 2,
  "frames_skipped": 380,
  "interval_seconds": 30
}
Analysis:
  • Skip rate: 76% (excellent, static scene)
  • Trigger rate: 2/120 = 1.7% (rare occurrence)
  • Cost efficiency: Very good
Conclusion: Efficient monitoring, condition is rare but detectable

​
Example 2: Frequent Events (High Trigger Rate)

{
  "checks_performed": 150,
  "triggers_fired": 45,
  "frames_skipped": 50,
  "interval_seconds": 30
}
Analysis:
  • Skip rate: 25% (lots of motion)
  • Trigger rate: 45/150 = 30% (very frequent)
  • Cost efficiency: Normal (busy scene)
Conclusion: High-motion area with frequent matching condition

​
Example 3: Poor Condition (Never Triggers)

{
  "checks_performed": 200,
  "triggers_fired": 0,
  "frames_skipped": 50,
  "interval_seconds": 30
}
Analysis:
  • Trigger rate: 0/200 = 0% (never)
  • Either:
    • The condition never occurs at this location
    • The condition is poorly written
    • The VLM can’t detect what you’re looking for
Solution:
  1. Test with Check Once
  2. Refine your condition (Writing Guide)
  3. Try a different location/stream

​
Monitoring Over Time

# Script to monitor skip rate over time
curl https://trio.machinefi.com/jobs/YOUR_JOB_ID | jq '.details | {
  checks: .checks_performed,
  skipped: .frames_skipped,
  skip_rate: (.frames_skipped / (.checks_performed + .frames_skipped) * 100 | round)
}'

# Output:
# {
#   "checks": 150,
#   "skipped": 112,
#   "skip_rate": 43
# }
Watch for changes:
  • Increasing skip rate → Scene becoming more static
  • Decreasing skip rate → Scene becoming more active
  • Sudden drop to 0 → Stream may have gone offline

​
Track Trigger Rate

Monitor how often your condition actually occurs: 
curl https://trio.machinefi.com/jobs/YOUR_JOB_ID | jq '.details | {
  checks: .checks_performed,
  triggers: .triggers_fired,
  trigger_rate: (.triggers_fired / .checks_performed * 100 | round)
}'
If the rate is unexpectedly low, see Debugging Guide