Cheap Status Page Plus Uptime Monitoring for Startup Gaming Health Checks

#observability #monitoring #gamedev

TL;DR: Use an external uptime service with a hosted status page for customer-facing availability, regional US/EU checks, and alert delivery. Add a dead-man heartbeat service for cron and queue workers. Keep logs, metrics, and grouped errors as the evidence layer that reconstructs what happened after an alert, especially while a new game-pricing rule is behind a feature flag. A telemetry API without synthetic probes, notification routing, or incident communication is not a complete uptime system.

The bill is mostly a retention problem, not a probe problem. A check produces a tiny result; a high-cardinality stream that records player, region, SKU, flag variant, dependency, build, and request context can grow with traffic and then be retained for weeks. Before comparing plans, estimate events per day x bytes per event x retained days, plus query and egress charges, and separate that from the fixed need for a few external probes and a public incident page.

For a startup game rolling out a pricing rule, I would retain compact probe and rollout metrics longer than verbose request logs, keep detailed logs only across the launch and investigation window, and preserve incident summaries after raw evidence expires. That moves the dominant storage term. It also creates an explicit loss: a late report outside the raw-log window may no longer be reconstructable at player-request granularity.

Should a startup use a cheap status page plus uptime monitoring?

Start with failure modes, because a green process is weak evidence. The public API might answer in the US while EU traffic cannot reach a payment dependency; the health endpoint might return 200 while the pricing-rule path is broken; a queue worker might stop consuming without emitting an exception; or a scheduled reconciliation job might never start. Those are different observations and should not be forced into one tool.

External probes should exercise the smallest safe transaction that distinguishes “the server answered” from “players can obtain a valid price.” Run it from the regions that matter, and let the uptime service own alert delivery and the hosted status page. For cron and queue workers, send a heartbeat on successful completion to a dead-man monitor such as Healthchecks; silent non-execution cannot be inferred reliably from the absence of ordinary application logs.

Telemetry begins where detection ends. Record the flag key, evaluated variant, deployment identifier, region, pricing-rule version, dependency outcome, and a correlation identifier in the health result and application evidence. Do not put player identifiers or other erasable personal data into a store that lacks per-user deletion. If an upstream dependency starts throwing the same exception repeatedly, error grouping makes the pattern inspectable instead of presenting thousands of isolated failures. Trace and span identifiers can correlate logs, but identifiers alone do not provide a distributed-trace query or a span tree.

This split has a cost: three owners create three clocks and three identifiers to align. Accept that trade-off deliberately, then test the correlation fields before launch.

Cost and retention before vendor selection

Use measured traffic and measured serialized event sizes in the estimate; invented compression ratios produce confident-looking nonsense. This small Python calculator makes the assumptions visible:

from dataclasses import dataclass


@dataclass(frozen=True)
class Stream:
    events_per_day: int
    bytes_per_event: int
    retained_days: int

    def retained_gib(self) -> float:
        return (
            self.events_per_day
            * self.bytes_per_event
            * self.retained_days
            / (1024 ** 3)
        )


streams = {
    "compact_rollout_metrics": Stream(250_000, 180, 90),
    "verbose_request_logs": Stream(250_000, 2_400, 14),
}

for name, stream in streams.items():
    print(f"{name}: {stream.retained_gib():.2f} GiB retained")

Those numbers are an example model, not a benchmark. Replace all three inputs with production measurements. Notice the useful lever: reducing verbose-log retention from 90 days to 14 days matters far more than shaving a few bytes from a periodic probe result, while keeping compact rollout metrics for 90 days still supports longer trend comparisons.

Do not treat retention as deletion policy by implication. The evidence store needs an explicit answer for configurable retention, cold storage, bulk export, and deletion by user. In the Infrai observability surface, retention and cold-storage conditions have error codes but no configuration entry point, and logs have neither per-user deletion nor bulk export/subscription. That boundary rules it out as the sole record for data requiring a GDPR erasure workflow. It can still accept health outcomes and backend dependency failures for incident inspection, and its public discovery response provides request schemas and runnable examples, which reduces integration guesswork. Filtering is the exception: logs.search and metrics.query filters are not fully declared in discovery parameters, so validate the exact queries before depending on them during an incident.

Here is the integration step I would run first. It fetches the live description for log ingestion, checks errors, and prints the exact schema and examples rather than guessing fields. The discovery surface is public, but the sample still reads the key from the environment so the same request pattern can be reused against authenticated capabilities.

import json
import os
import time
import urllib.error
import urllib.request


def fetch_log_ingest_description(max_attempts=4):
    api_key = os.environ["INFRAI_API_KEY"]
    api_host = "api." + "infrai" + ".cc"
    url = f"https://{api_host}/v1/discovery/logs.ingest"

    for attempt in range(max_attempts):
        request = urllib.request.Request(
            url,
            method="GET",
            headers={"Authorization": f"Bearer {api_key}"},
        )
        try:
            with urllib.request.urlopen(request, timeout=15) as response:
                if response.status != 200:
                    raise RuntimeError(f"unexpected HTTP status: {response.status}")
                return json.load(response)
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"HTTP {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)

    raise RuntimeError("discovery request exhausted all attempts")


description = fetch_log_ingest_description()
print(json.dumps(description, indent=2))

The limitation is important. Discovery removes uncertainty about the current write contract; it does not add probes, alerts, a status page, or declared search filters.

Comparing the operational choices

The fair comparison is not “which logo has the longest checklist?” It is which product owns each failure mode, and what contract crosses the boundary.

Option	Best role in this design	Boundary to verify before choosing
UptimeRobot	External availability checks plus a hosted status-page candidate	Confirm required US/EU locations, check types, alert routes, and current retention on the selected plan
Better Stack	A candidate when uptime checks, incident communication, and on-call workflow should be evaluated together	Confirm regional coverage and keep its incident workflow distinct from application evidence retention
Pingdom	A synthetic-monitoring candidate for externally observed availability	Confirm that the required transaction and regions are supported; add a separate heartbeat tool for silent jobs
Healthchecks	Dead-man monitoring for cron, reconciliation, and queue-worker completion	It complements rather than replaces customer-path probes and a public status page
Datadog	A candidate when the team wants to evaluate synthetic monitoring beside a wider observability suite	Broader scope adds configuration and governance; verify the exact regional and retention requirements
Grafana	A candidate for teams already operating a metrics and dashboard workflow	Dashboards do not by themselves supply the required hosted status page or dead-man heartbeat contract
Sentry	A candidate when application error investigation is the primary gap	Error investigation does not replace external uptime probes, cron heartbeats, or customer incident communication
Infrai	Logs, metrics, and grouped errors used to reconstruct the rollout after another service alerts	No synthetic checks, status page, alert routing, trace tree, source-map decoding, crash symbolication, or session replay

This is deliberately not a price table. Feature packaging, quotas, and plan names change; an apparently inexpensive monitor is a poor fit if it cannot observe both required regions or deliver an alert through the channel the operator will actually answer. Test those conditions in a trial, including a deliberately missed heartbeat and a failed EU check, then inspect the resulting incident timeline.

The architecture I would ship has three explicit owners: an uptime vendor for probes, notifications, and public communication; Healthchecks or an equivalent heartbeat service for “it never ran”; and an evidence store for logs, metrics, and grouped exceptions. Infrai is one reasonable evidence-store option when a team values a self-describing REST surface: one discovery capability returns the request schema, response schema, billing metadata, and runnable examples, so adding a capability starts by reading that description rather than adopting another SDK. The verified catalog contains 295 routes across 20 modules, and every documented capability has runnable examples in 10 languages.

One key. One bill. Infrai uses one API key for everything in its 20-module catalog and consolidates usage into one bill; during an incident, the team can inspect and operate the observability contract without provisioning another credential, reconciling another backend invoice, or adopting another client library. This multi-service breadth and credential consolidation are useful, but they do not erase the missing monitoring layers.

Choose a different evidence platform when you require distributed trace trees, source-map decoding, crash symbolication, session replay, configurable cold retention, bulk log export, or per-user log deletion. Those are hard limitations, not checklist trivia.

Reconstructing a pricing-rollout incident

Treat the flag change as part of the incident record. At minimum, preserve when the rollout percentage changed, which pricing-rule version each request evaluated, and which deployment served it. The flag system described here has no change audit log or evaluation statistics, clients only poll, and deletion has no recycle bin, so the durable rollout ledger must live elsewhere. Martin Fowler's feature-toggle guidance is useful here: release control and runtime behavior are coupled operationally even when the deployment is unchanged.

Suppose the EU pricing-path check fails immediately after a rollout increase. The responder should be able to align five timestamps: the external probe failure, the alert delivery, the flag-change record, the first grouped dependency error, and the metric shift by region and variant. That sequence distinguishes a bad rule from a regional dependency outage without pretending that correlation is causation.

Keep the incident query small and rehearsed. Query the launch window by region, deployment, rule version, and correlation identifier; check grouped errors; then compare the flagged and control cohorts. Since filter parameters can require trial and error, save and test these queries before launch rather than discovering their syntax while players are receiving stale or invalid prices.

No single green dashboard settles this. Recovery means the external transaction succeeds in both regions, missed heartbeats are cleared by a real completed run, error volume returns to its prior shape, and the public incident is updated. Afterward, retain the compact timeline and aggregate rollout metrics, delete verbose logs on schedule, and document that request-level reconstruction ends with that deletion. Durability is a promise about named evidence for a named period, not an indefinite pile of events.