Monitor Modes

Deep dive into Timeout, Auto, and Frequency monitoring modes

Overview

Telemetry.host offers three monitoring modes to accommodate different use cases. Understanding when to use each mode will help you create more reliable monitors.

How It Works

Alert if no check-in received within the specified timeout period. Each check-in resets the timer.

URL Pattern

/ping/{PROJECT_KEY}/timeout/{TIMEOUT}/{MONITOR_SLUG}?create=1

Timeout Format

  • 30s - 30 seconds
  • 5m - 5 minutes
  • 1h - 1 hour
  • 1d - 1 day
  • 1w - 1 week
  • 1d6h30m - 1 day, 6 hours, 30 minutes

When to Use

  • Known schedules: Daily, hourly, etc.
  • Simple monitoring: Just want to know if job ran
  • Most cron jobs: Predictable intervals

Examples

Daily backup (runs at 2 AM):

# Timeout: 25 hours (allows for 1 hour delay)
curl -X POST \
  https://telemetry.host/ping/abc123/timeout/25h/daily-backup?create=1

Hourly task:

# Timeout: 90 minutes (allows for 30 min delay)
curl -X POST \
  https://telemetry.host/ping/abc123/timeout/90m/hourly-cleanup?create=1

Best Practices

  1. Add buffer time: If job runs daily, use 25-26 hour timeout
  2. Account for maintenance: Consider maintenance windows
  3. Monitor critical path: Don’t set timeout too loose

Auto Mode (Adaptive)

How It Works

Learns check-in patterns from historical data and automatically adapts to changes.

URL Pattern

/ping/{PROJECT_KEY}/auto/{MONITOR_SLUG}?create=1

Learning Phase

  1. First 2-4 check-ins: Collecting pattern data (status: LEARNING)
  2. 5+ check-ins: Active monitoring begins
  3. Continuous: Adapts to pattern changes

When to Use

  • Variable intervals: Job frequency changes based on load
  • Unknown schedules: Inheriting existing system
  • Adaptive workloads: Auto-scaling services

Algorithm

Expected Interval = Median of last 10 intervals
Tolerance = Standard deviation * 2
Alert if: Time since last check-in > Expected + Tolerance

Examples

Variable backup (runs when data changes):

curl -X POST \
  https://telemetry.host/ping/abc123/auto/smart-backup?create=1

Auto-scaling service:

# Adapts as replicas scale up/down
curl -X POST \
  https://telemetry.host/ping/abc123/auto/web-service-health?create=1

Best Practices

  1. Stable patterns work best: Auto mode needs consistency
  2. Min 5 check-ins: Wait for learning phase
  3. Not for random intervals: Use timeout mode instead
  4. Monitor the monitor: Check it’s learning correctly

Frequency Mode (Legacy)

How It Works

Traditional “expected frequency + grace period” model inherited from healthchecks.io.

URL Pattern

/ping/{PROJECT_KEY}/{FREQUENCY}/{GRACE}/{MONITOR_SLUG}?create=1

When to Use

  • Migrating from healthchecks.io: Familiar model
  • Explicit grace control: Need fine-tuned grace period
  • Backward compatibility: Existing URLs

Examples

Daily job with 30-minute grace:

curl -X POST \
  https://telemetry.host/ping/abc123/24h/30m/daily-job?create=1

Hourly with 10-minute grace:

curl -X POST \
  https://telemetry.host/ping/abc123/1h/10m/hourly-task?create=1

Timeout vs Frequency

These are equivalent:

# Timeout: 24h30m
/ping/KEY/timeout/24h30m/job

# Frequency: 24h frequency + 30m grace
/ping/KEY/24h/30m/job

Use timeout mode - it’s simpler and more intuitive.

Comparison Table

FeatureTimeoutAutoFrequency
Simplicity✅ Simple⚠️ Complex⚠️ Moderate
Predictable✅ Yes⚠️ Adaptive✅ Yes
Setup required✅ Just timeout❌ Needs history⚠️ Two values
Adapts to changes❌ No✅ Yes❌ No
Best forKnown schedulesVariable patternsMigration

Mode Selection Guide

Choose Timeout Mode If:

  • ✅ You know how often the job runs
  • ✅ Schedule is predictable
  • ✅ You want simplicity
  • ✅ First time setting up monitoring

Example: Daily backup, hourly cleanup, weekly reports

Choose Auto Mode If:

  • ✅ Job frequency varies
  • ✅ You’re monitoring existing system with unknown schedule
  • ✅ Workload is adaptive (scales with demand)
  • ✅ You want hands-off monitoring

Example: Event-driven tasks, auto-scaling services, load-based processing

Choose Frequency Mode If:

  • ✅ Migrating from healthchecks.io
  • ✅ You prefer explicit grace periods
  • ✅ Backward compatibility needed

Example: Existing monitoring URLs, team familiar with this model

Switching Modes

You can change monitor mode after creation:

  1. Go to monitor settings
  2. Change “Mode” dropdown
  3. Update configuration (timeout/frequency/grace)
  4. Save changes

Note: Switching to Auto mode resets learning - needs 5+ check-ins to activate.

Advanced Patterns

Combining Modes for Redundancy

Monitor critical jobs with both timeout and auto:

# Primary: Timeout mode (known schedule)
curl -X POST https://telemetry.host/ping/KEY/timeout/25h/backup-primary

# Secondary: Auto mode (catches pattern changes)
curl -X POST https://telemetry.host/ping/KEY/auto/backup-secondary

Weekend vs Weekday Schedules

For jobs with different weekend schedules, use timeout with maximum interval:

# Runs weekdays (24h), but 72h on weekends
# Use 73h timeout to cover both
curl -X POST https://telemetry.host/ping/KEY/timeout/73h/business-report

Or create separate monitors:

# Weekday monitor
if [ $(date +%u) -lt 6 ]; then
    curl https://telemetry.host/ping/KEY/timeout/25h/weekday-report
fi

# Weekend monitor  
if [ $(date +%u) -ge 6 ]; then
    curl https://telemetry.host/ping/KEY/timeout/73h/weekend-report
fi

Troubleshooting

Timeout Too Aggressive

Symptoms: False positive alerts, monitor flapping

Solutions:

  • Increase timeout buffer
  • Check if job duration is increasing
  • Verify network connectivity

Auto Mode Not Learning

Symptoms: Stuck in LEARNING state

Causes:

  • Less than 5 check-ins received
  • Check-ins too infrequent
  • Pattern too random

Solutions:

  • Wait for more check-ins
  • Consider timeout mode instead
  • Check logs for failed check-ins

Frequency Mode Confusion

Symptoms: Unsure what values to use

Solution: Use timeout mode instead - it’s simpler:

  • Timeout = Frequency + Grace

Next Steps