Feature Request: Configurable maxRetries and timeout for HTTP (curl) and Globalping checks

[NFnesrine]

Feature Request: Configurable maxRetries and timeout for HTTP (curl) checks

Problem

Currently, maxRetries, connectTimeout, and requestTimeout per-site options (introduced in uptime-monitor#277) only work for check: tcp-ping. For standard HTTP checks (curl), the retry logic is hardcoded in update.ts:

// Always 3 attempts, always 2s + 10s delays — no way to configure this
await wait(2000);
const secondTry = await performTestOnce();
// ...
await wait(10000);
const thirdTry = await performTestOnce();

This means that when multiple sites are confirmed down (not false positives), the workflow takes an extremely long time because each site always does 3 attempts with fixed 2s + 10s delays, and there is no way to reduce this from .upptimerc.yml.

Important distinction

The 3-retry logic is useful and correct for catching false positives (as discussed in #171). The problem is that when sites are genuinely and persistently down, users have no way to reduce retries to save workflow time. Both use cases should be supported.

Real-world example

Monitoring 12 sites where 4 are confirmed down for days, using Globalping. Each down site fetches 3 measurements:

Fetching globalping measurement ...
Fetching globalping measurement ...
Fetching globalping measurement ...
Skipping commit, status is down

Result: workflow takes 2m 30s+ on every run, wasting GitHub Actions minutes unnecessarily.

Expected behavior

maxRetries, connectTimeout and requestTimeout should work for all check types, including standard HTTP (curl) and Globalping — not just tcp-ping.

Proposed per-site config:

sites:
  - name: My Site
    url: https://example.com
    maxRetries: 1        # default: 3 — should apply to HTTP curl too
    connectTimeout: 10   # seconds
    requestTimeout: 15   # seconds

And a global fallback in .upptimerc.yml:

maxRetries: 1       # applies to all sites unless overridden per-site
connectTimeout: 10
requestTimeout: 15

Related

• Specific timeout value or retry value / Timeout overlaps next uptime check #470 — original request for configurable timeout/retries, open since 2021
• uptime-monitor#277 — introduced per-site options but only implemented for tcp-ping
• HTTP 0 response code for a URL #171 — HTTP 0 false positives (the retry logic exists for good reason, but needs to be configurable)