API monitoring without the per-check taxUnlimited on every paid plan
HTTP and API monitors are unlimited on every paid plan, with no per-check charge. Define assertions, get timing breakdowns, and ship OTel insight packs from 14 locations.
monitors:
- name: Payment API
type: http
url: https://api.example.com/v1/payments
method: POST
frequency: 1m
locations: [us-east, eu-west, ap-southeast]
assertions:
- type: status_code
value: 200
- type: response_time
operator: less_than
value: 500
- type: json_body
path: $.status
value: healthy
How it works
HTTP check defined with assertions
Define your endpoint URL, method, headers, body, and assertions in YAML. No code required.
Runs from selected locations
Check executes from your configured locations at your configured frequency.
Full timing breakdown + TLS inspection
DNS lookup, TCP connect, TLS handshake, and TTFB timed separately. Certificate inspected.
OTel insight pack emitted
Timing phases, TLS details, assertion results, and anomaly scores emitted as a full OTLP insight pack.
Assertions on everything
Assert on status code, response time, JSON body fields, response headers, and body content. Chain multiple assertions; all must pass for the check to succeed.
status_codeequals 200response_timeless_than 500msjson_body$.status equals healthyheadercontent-type contains jsonbody_containsstring present in bodybody_not_containsstring absent from bodyassertions:
- type: status_code
value: 200
- type: response_time
operator: less_than
value: 500
- type: json_body
path: $.data.status
value: active
- type: header
name: content-type
operator: contains
value: application/json
- type: body_contains
value: "healthy"Full timing breakdown in OTel
DNS lookup, TCP connect, TLS handshake, and TTFB timed separately and emitted as individual OTel gauge metrics. Anomaly-scored against 14-day baselines per location.
When your TLS handshake starts taking 3× longer, it shows up as a timing anomaly in your backend, not just a slow total response time that requires digging to diagnose.
synthetics.dns.lookup_durationsynthetics.tcp.connect_durationsynthetics.tls.handshake_durationsynthetics.ttfb.durationsynthetics.http.response_timeTLS inspection built in
Certificate expiry, issuer chain, fingerprint, and days-until-expiry emitted as span attributes on every HTTPS check. Alert before a user sees a browser warning.
Configure your expiry alert threshold: get notified at 30 days, 14 days, or 7 days remaining. Not at zero, when it's already a user-facing problem.
# Emitted on every HTTPS check
synthetics.tls.days_until_expiry 42
synthetics.tls.valid_to 2026-05-15T00:00:00Z
synthetics.tls.issuer_cn Let's Encrypt
synthetics.tls.subject_cn api.example.com
synthetics.tls.fingerprint_sha256 a1b2c3d4...
# Emitted as an OTel metric (not a span attribute)
synthetics.tls.handshake_duration 45Unlike per-check pricing models
Most tools charge per HTTP check per location per month. Unlimited means unlimited: define as many monitors as your infrastructure needs without a per-check budget conversation.
Every HTTP check emits a full OTel insight pack (timing phases, TLS details, and anomaly scores), not just response_time and pass/fail.
Fair use applies (500K hosted / 1M private per month). This covers hundreds of monitors running every minute across multiple locations.
Frequently asked
What does 'unlimited HTTP checks' actually mean?
HTTP and API monitors are unlimited on every paid Yorker plan, with no per-check charge. Generous fair-use limits apply (500,000 hosted and 1,000,000 private-location executions per month), enough for hundreds of monitors running every minute across multiple locations.
Which assertion types are supported?
status_code, response_time (with operators: equals, less_than, greater_than), json_body (JSONPath expression + expected value), header (header name + operator + value), body_contains, and body_not_contains. All assertions are defined in YAML; multiple assertions can be chained on one monitor and all must pass for the check to succeed.
How does TLS certificate monitoring work?
Every HTTPS check automatically inspects the TLS certificate and emits expiry date, days-until-expiry, issuer CN, subject CN, and SHA-256 fingerprint as OTel span attributes. TLS handshake duration is emitted as a separate gauge metric (synthetics.tls.handshake_duration). Alert thresholds for certificate expiry (e.g. warn at 30 days, critical at 7 days) are configured in your alert rules.
What timing phases does Yorker measure on HTTP checks?
DNS lookup, TCP connect, TLS handshake, and TTFB (time to first byte) are timed separately and emitted as individual OTel gauge metrics. Each phase is anomaly-scored against a 14-day rolling baseline per location, so a TLS regression shows up as a timing anomaly in your backend rather than being buried in a slow total response time.
Can I define HTTP monitors in code and deploy via CI/CD?
Yes. Define monitors in a yorker.config.yaml file, commit it to your repository, and run npx @yorker/cli apply in your CI pipeline. The CLI diffs your declared state against what is live and applies only the changes — the same plan-then-apply pattern as Terraform. No manual steps in the web UI.
Put your first check live in one command.
Free tier includes 10,000 HTTP + MCP checks and 1,500 browser checks per month. No credit card required.
npx @yorker/cli init