Monitor frequency

Frequency is the most-tweaked setting in DevFlow. It governs cost, alert latency, and the false-positive rate.

the three speeds

• 30 seconds — Pro and Scale tier. Best for revenue-critical APIs (checkout, auth, write paths). Sub-10-second checks are available on Scale.
• 60 seconds — the default. Good for most user-facing reads.
• 5 minutes — adequate for back-office and async-only paths. Cheap.

a rule of thumb

If a five-minute outage on this endpoint would be embarrassing, you want 30s checks. If five minutes is fine, 60s. If you wouldn't notice for an hour, 5m.

interaction with assertions

A 30-second monitor that times out at 5 seconds and retries 3x with exponential backoff can spend almost half its window in retry. Keep timeouts and retry policy honest — see retry-policy for the full math.

interaction with SLOs

If you're tracking a 99.9% SLO over a 28-day window, a 60s monitor gives you 40,320 data points. That's enough resolution for a slo-multi-window-alerting short-and-long-window strategy. A 5m monitor only gives 8,064 — workable, not great.

cost

The headline number on [doc:monitor-frequency-pricing... etc] (see /pricing) is per-monitor per-month at one frequency, in one region. Multi-region multiplies. We don't charge for assertion count or response size on Pro+ tiers. The full table is on /pricing.

changing frequency safely

Going faster: no risk, just verify nothing else is watching for run cadence (e.g. some Datadog dashboards aggregate per-minute).

Going slower: be careful. SLO accounting is per-data-point. A monitor that goes from 30s → 5m won't lose history but its resolution drops.