Skip to main content

rawops.dev

RawMon Docs

Native Monitoring

How RawMon's native monitoring engine works: 7 check types, background scheduling, certificate thresholds, and platform behavior.

Last updated: 2026-04-24

How Native Checks Work

In native monitoring mode your phone performs checks directly — no external server or cloud service is involved. RawMon's check engine dispatches requests from the device, measures response time, evaluates pass/fail criteria, and stores heartbeat results in a local SQLite database.

Check Engine Types

HTTP

Sends an HTTP(S) request to the target URL. Validates the response status code (default: 2xx), measures response time, and optionally searches for a keyword in the response body. Supports custom headers, authentication, and the option to ignore TLS certificate errors.

DNS

Resolves DNS records using Cloudflare's DNS-over-HTTPS (DoH) endpoint. Supports A, AAAA, CNAME, MX, and TXT record types. The check passes if the expected value appears in the response records.

TCP

Opens a TCP connection to the specified host and port. Measures connection time. Useful for checking database ports, mail servers, game servers, or any TCP service.

ICMP Ping

Sends ICMP echo requests to measure round-trip time and packet loss. Available on iOS via a raw socket implementation.

TLS Certificate

Connects via TLS and inspects the server certificate. Reports expiry date, issuer, subject, and chain validity. Supports multi-threshold warnings — configure multiple day thresholds (e.g., 30, 14, 7 days) to receive escalating warnings as expiry approaches. The lowest threshold triggers a DOWN status; higher thresholds produce WARNING status.

Heartbeat

A passive check that expects periodic pings from your scripts, cron jobs, or CI pipelines. Each heartbeat monitor gets a unique token. If no ping arrives within the configured grace period, the monitor goes DOWN.

Metric Evaluation

Evaluates numeric values sent by script monitors against configurable thresholds. Supports operators: greater than, less than, equal, not equal. Useful for disk usage, memory, queue depth, or any custom metric.

Interval, Timeout & Retries

Each monitor has three timing parameters:

  • Interval — How often to check (default: 60s, range: 10s to 24h)
  • Timeout — Maximum wait time per check (default: 10s)
  • Retries — Number of consecutive failures before marking DOWN (default: 1, max: 10)

Background Checking

iOS

RawMon runs background checks through three independent layers, all writing to the same local heartbeat store:

  1. Silent push wake (v1.1.2+) — the RawMon push relay fires a silent content-available push to your device approximately every 60 minutes (per-device cadence; previously 30 min, halved in v1.2.0 to stay safely under Apple's documented 2–3 silent-pushes-per-hour APNs budget). On arrival iOS attempts to wake the JavaScript runtime long enough to execute a full check cycle. This path is still subject to the iOS DAS scheduler's Energy Budget scoring — when the app has been off-charger and recently foregrounded, DAS may drop individual wake pushes. Most reliable while the device is charging overnight.
  2. BGProcessingTask — a longer background window (up to ~30 s) that iOS grants while the device is idle. In practice this fires most often overnight, typically once every 30 minutes on a charger.
  3. BGAppRefreshTask — a lightweight refresh slot iOS schedules opportunistically (~15–30 min) based on your usage pattern.

The three layers cooperate through a mutex so they never run overlapping check cycles. All results land in the same dashboard history and feed the same incident and notification pipeline.

For instant 24/7 alerting: pair native checks with webhook integrations (Kuma, Prometheus, Grafana, etc.). Webhook sources push notifications immediately when your server detects an outage, with no polling latency at all.

You can inspect recent background activity under Settings > Background Checks > View Log — it shows the last 20 executions with timestamp, result, and duration.

Background checks work most reliably when:

  • Push notifications are allowed in iOS Settings > RawMon (required for the silent-push layer).
  • Background App Refresh is enabled in iOS Settings > General > Background App Refresh.
  • Low Power Mode is off.

Android

Uses a persistent Foreground Service with a notification icon. Checks are scheduled via AlarmManager.setAndAllowWhileIdle, which is the only Doze-resistant scheduling primitive available without flagged "sensitive" permissions (SCHEDULE_EXACT_ALARM is reserved for alarms/calendar apps and triggers Play Console review scrutiny). A deduplication guard prevents overlapping check cycles when the app resumes from background.

Doze batching reality. Android consolidates background work in low-power "Doze" mode to save battery. setAndAllowWhileIdle is allowed to fire during Doze but is batched into maintenance windows: 1 fire per ~9 minutes in shallow Doze, stretching to 15–30 minutes in deep idle. If you set 5-minute checks but the phone has been idle for hours, you may see actual checks land every 15–30 minutes. This is Android operating-system behavior, not a RawMon bug. To minimize stretching:

  1. Set Battery Optimization → Unrestricted for RawMon in system Settings (Settings → Apps → RawMon → Battery).
  2. Keep the phone awake (any user interaction in the past hour) — Doze deepens with prolonged idle.
  3. For real-time off-charger alerts, connect a SaaS provider (Kuma, UptimeRobot, Better Stack, etc.) — provider state-changes arrive via FCM high-priority push, which bypasses Doze entirely.

Limitations

  • Internet required — Your phone must have an active network connection for checks to execute.
  • Battery impact — Frequent checks (under 60s) with many monitors will increase battery consumption. The foreground service on Android is particularly impactful.
  • iOS silent-push budget — Apple caps content-available pushes at roughly 2–3 per hour per device. RawMon's 60-minute cadence (v1.2.0+) stays comfortably inside that budget. If the budget is exhausted for other reasons (e.g. cumulative DAS scoring penalties from past wake events) iOS can drop individual wake pushes; the next one still arrives on schedule. For zero-latency alerting use webhook integrations (Kuma, SaaS providers) which bypass the silent-push path entirely.
  • ICMP — Ping checks are iOS-only due to Android socket restrictions.
  • DNS — All DNS queries route through Cloudflare DoH (1.1.1.1). You cannot use a custom DNS resolver.