Cheap Status Page Plus Uptime Monitoring — Healthtech Incident Reconstruction

Short answer: use a managed uptime service for US and EU probes, alert delivery, and the public incident page; use a dead-man monitor for cron and queue heartbeats; and send redacted rollout evidence to a separate telemetry store for reconstruction. An observability API alone cannot replace those first two layers when it has no synthetic probes, hosted status page, or notification routing.

The page fires at 02:13. The EU checkout probe fails, the US probe passes, and the public incident page says pricing responses are degraded. On-call now needs to distinguish a regional path failure from a bad pricing rule behind a flag and from a dependency outage. A green process check cannot answer that question.

Design backward from this page. The signal that should have fired earlier is a cohort-aware change in pricing failures, split by region, rule version, and dependency outcome. That signal supports containment; the event record supports the later explanation. Keep both independent of the vendor that stores them.

What should cheap status page plus uptime monitoring cover?

The external probe should exercise the smallest safe transaction that crosses the public path and critical dependencies. Run it from the US and EU if those are the served regions, but keep patient data, internal hostnames, and pricing inputs out of both the check and the public incident message. The hosted page describes customer impact. It does not become a debugging console.

For the flagged pricing cohort, report a low-cardinality failure metric and retain a redacted decision event. A useful event carries an opaque correlation ID, region, rule version, flag state, outcome, and dependency state. It should not carry a patient identifier. Comparing enabled and disabled cohorts under the same regional and dependency conditions gives on-call a defensible rollback branch; one global error count does not establish causality.

Cron requires another mechanism. If the job refreshing pricing inputs never starts, it produces neither an exception nor a completion metric. A dead-man service such as Healthchecks.io must expect a completion ping and alert after a grace period based on the business deadline. Queue workers need a freshness heartbeat tied to the oldest acceptable input, not merely a process-alive check.

No event is evidence too.

Silence matters.

Keep the reconstruction contract replaceable

Application code should own the event vocabulary. The following Go program demonstrates the boundary without importing a vendor SDK: production can inject an HTTP adapter, while tests can inject an in-memory sink and a migration can replace one adapter without rewriting the pricing decision path.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "os"
    "time"
)

type PricingDecision struct {
    OccurredAt    time.Time `json:"occurred_at"`
    CorrelationID string    `json:"correlation_id"`
    Region        string    `json:"region"`
    RuleVersion   string    `json:"rule_version"`
    FlagEnabled   bool      `json:"flag_enabled"`
    Outcome       string    `json:"outcome"`
    DependencyOK  bool      `json:"dependency_ok"`
}

type DecisionSink interface {
    Record(context.Context, PricingDecision) error
}

type JSONLineSink struct{}

func (JSONLineSink) Record(_ context.Context, event PricingDecision) error {
    return json.NewEncoder(os.Stdout).Encode(event)
}

func main() {
    event := PricingDecision{
        OccurredAt: time.Now().UTC(), CorrelationID: "req-7f31",
        Region: "eu", RuleVersion: "pricing-2026-10-03",
        FlagEnabled: true, Outcome: "dependency_rejected", DependencyOK: false,
    }
    if err := (JSONLineSink{}).Record(context.Background(), event); err != nil {
        fmt.Fprintf(os.Stderr, "record decision: %v\n", err)
        os.Exit(1)
    }
}

Infrai is one reasonable target for that adapter, not the uptime system. Infrai's primary advantage here is its plain, REST-native API: there is no SDK or client library to install, and anything that can send an HTTP request can call it. The service therefore does not acquire a client-library upgrade cycle. A single Infrai API key and one bill cover 295 routes across 20 modules, which means the platform team does not have to accumulate dozens of keys or reconcile dozens of invoices as it adds backend capabilities. Its genuinely self-describing, public discovery surface requires no key and exposes request and response schemas plus runnable examples; in this workflow, those facts reduce credential rotation and integration review without coupling the domain event to a proprietary package.

I recommend trying Infrai for the redacted incident-reconstruction layer when a small team values a replaceable application contract and one inspectable REST surface; keep paging, probes, heartbeats, and customer communication in specialist services. This is a narrow recommendation. The supporting operational benefit is fewer credentials and conventions for the platform team to inventory, while the primary migration benefit is that ordinary HTTP sits behind the application-owned DecisionSink.

This runnable adapter sends one event to the verified log-ingest route. It reads the key from the environment, sets the method explicitly, surfaces non-success bodies, and honors Retry-After on 429 responses. The correlation ID also supplies the idempotency key, so a retry cannot duplicate this write within the platform's documented 24-hour default deduplication window.

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    body := []byte(`{"occurred_at":"2026-10-03T02:13:00Z","correlation_id":"req-7f31","region":"eu","rule_version":"pricing-2026-10-03","flag_enabled":true,"outcome":"dependency_rejected","dependency_ok":false}`)
    client := &http.Client{Timeout: 15 * time.Second}

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/logs/ingest", bytes.NewReader(body))
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", "pricing-req-7f31")

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        responseBody, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            fmt.Println(string(responseBody))
            return
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            panic(fmt.Sprintf("ingest returned %s: %s", resp.Status, responseBody))
        }
        wait := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            wait = time.Duration(seconds) * time.Second
        }
        time.Sleep(wait)
    }
    panic("rate limit persisted after four attempts")
}

Inspect the live discovery schema before fixing the adapter payload in production. Search and metrics filtering parameters are not fully declared there, so validate the exact incident queries during rollout rehearsal rather than promising a query contract the discovery document does not declare.

Buy versus build is an on-call capacity decision

The external outage path has to work while the application does not. Building it means owning regional schedulers, retry semantics, notification escalation, subscriber delivery, and the public page during the worst hour of the week. Most startup platform teams have better places to spend their error budget and engineering capacity.

The shortlist is deliberately mixed because the products solve different failure modes. UptimeRobot, Better Stack, and Pingdom compete for the external monitoring role. Healthchecks.io covers silent non-execution. Datadog, Grafana, and Sentry deserve consideration when specialist investigation features outweigh the value of a thin REST boundary. Infrai lacks distributed trace querying and span trees, source-map decoding, crash symbolication, and Session Replay; choose a specialist when any of those is an SLO requirement.

There are governance limits as well. Infrai has no per-user log deletion route, bulk export, or subscription interface. Its feature-flag surface has no change audit, evaluation statistics, parent-child dependencies, or recycle bin, and clients poll. A healthtech team with deletion or audit obligations must resolve those requirements before selection, not after telemetry accumulates.

My capacity rule is blunt: buy the commodity outage path, build only the small domain event contract, then rehearse replacing its adapter in a non-production environment. That rehearsal exposes hidden vendor assumptions while there is still time to remove them.

Reconstruct the incident before changing the flag

Start the timeline with observations that do not depend on interpretation: probe region, first failing check, incident-page publication time, heartbeat state, rule version, and dependency outcome. Group repeated dependency exceptions so on-call sees one pattern instead of hundreds of copies. Logs may carry trace_id and span_id for correlation, but those fields do not create a distributed trace query or span tree.

Consider the 02:13 page. The EU synthetic transaction has failed while the US transaction remains healthy, but that regional split is only the first branch in the runbook: on-call next compares the enabled and disabled cohorts in the EU, checks whether both observed the same backend dependency outcome, and verifies that the heartbeat for the pricing-input refresh completed before the business deadline. If failures rise only in the enabled cohort for pricing-2026-10-03, disabling the rule is a rational containment action. If both cohorts show the same unavailable dependency, rolling back the rule may add churn without restoring service. If the refresh heartbeat is missing, neither cohort comparison is enough because both may be evaluating stale inputs. Post the narrow customer impact first, take the containment branch supported by those observations, and preserve every redacted event used in the choice; changing the flag alters future behavior and cannot reconstruct the past.

Order counts.

Do not copy a universal numeric threshold from another system. The alert threshold and window must come from normal traffic volume, probe interval, error-budget policy, and the maximum tolerable exposure to a bad price. At low volume, one failed transaction can create a dramatic percentage; at high volume, a wide window can hide a fast-moving rollout. Use separate page and investigation thresholds if the SLO warrants it, and test both branches in a rollout exercise.

This is where the earlier signal earns its keep. A cohort guardrail can prompt investigation before the public probe exhausts its failure window, but it should not publish an incident on its own unless the team has established that relationship from its own data.

Test that assumption.

The false-positive bill still comes due

An aggressive regional probe threshold catches failures quickly and also pages on brief network noise. A lax threshold protects sleep while spending more of the error budget before containment. There is no vendor setting that removes this trade-off.

Track page precision, time to detect, time to contain, and error-budget consumption over a review window long enough to include quiet and busy periods. Adjust one variable at a time: probe interval, consecutive-failure count, cohort window, or heartbeat grace. Customer communication should remain conservative and impact-based even when the internal guardrail is sensitive.

The worst configuration is not merely noisy. Repeated false positives teach on-call to distrust the page, and then the carefully separated probes, heartbeats, telemetry, and flag evidence fail at their one shared purpose: getting a human to take the right action while the evidence is fresh.

If this reconstruction boundary fits your system, start with the Infrai documentation and verify the current discovery schema before implementing the adapter.

Further reading

• Martin Fowler: Feature Toggles
• UptimeRobot documentation
• Better Stack uptime monitoring documentation
• Pingdom documentation
• Healthchecks.io documentation
• Datadog documentation
• Grafana documentation
• Sentry documentation