4 Better Uptime Signals Beyond Self-Hosted Health for Media SaaS

A media SaaS team should buy an external uptime service for public endpoint availability, then keep application-generated metrics and structured logs for diagnosing the AI agent loop. TL;DR: page on reader-visible failure, not on every slow model call. Track four bounded internal signals—total loop duration, terminal outcome, model-call latency, and per-call cost metadata when the model surface supplies it—but treat them as evidence after the page, not as proof that a reader in the US or EU can reach the product.

The page arrives first. On-call sees a failed public check, its observation time, and the probe location. The useful next screen is not a wall of logs; it is a narrow account of whether retrieval, generation, or publication spent the latency budget, and whether the loop completed at all.

A green self-hosted health endpoint cannot see broken DNS, TLS, an edge route, or a failure outside its own network path. Conversely, an external probe can report that the front door is shut without explaining which agent stage stalled. Those are different jobs.

Work backward from the reader-visible failure. The earlier signal should be a sustained SLO symptom: end-to-end loop duration consuming its budget, terminal failures across a meaningful request window, or a scheduled publishing job failing to report that it ran. One slow generation is diagnostic evidence. It is not an incident.

This is where signal quality beats feature count. A threshold that wakes someone must correspond to an action: inspect the edge, isolate a bounded loop stage, or investigate missing scheduled work. If the responder cannot name the first action, the alert is merely an expensive notification.

Media traffic makes static thresholds particularly suspect. Publication bursts can raise latency while the service remains useful, and a low-traffic interval can make a percentage unstable. Choose an availability SLO and an evaluation window before choosing a threshold; then record both false pages and user-visible misses. Capacity planning belongs in the same discussion because a finer set of labels consumes more series before it improves a decision.

Ten loop stages multiplied by three outcomes, four model families, and two regions create 240 possible combinations before replicas or status codes enter the picture. Keep stage, outcome, model family, and region bounded. Article IDs, reader IDs, prompt text, URLs, trace IDs, and request IDs belong outside metric labels. Prometheus explains why: each unique label combination creates a new time series.

Small sets win.

Time the complete agent loop and its stable stages, emit one terminal outcome such as success, timeout, or error, and reserve structured logs for details that actually change an investigation. Do not collect prompts, drafts, personal identifiers, or full URLs by default. GDPR Article 5 makes data minimization a processing principle, and an observability store should not become an accidental second content archive.

Per-call metadata can sharpen that account. Infrai's native and OpenAI-compatible AI surfaces specify cost, vendor, latency, cache status, and request ID metadata. Their presence supports correlation; it does not establish measured uptime, latency, or savings. Logs can also carry trace_id and span_id, but correlation fields are not a distributed trace query or a span tree. Teams that need trace exploration, source-map decoding, crash symbolication, Electron minidump analysis, or Session Replay should use a product built for those workflows.

The instrumentation boundary should stay off the synchronous reader path. If losing an event is unacceptable, put a bounded buffer or worker behind the request and include that capacity in the failure budget. Infinite retries turn an observability impairment into a publishing impairment.

For Infrai, the safest first integration step is contract discovery rather than a guessed payload. Its public discovery surface returns the request and response schemas, billing information, and runnable examples without requiring a key; documented capabilities include examples in 10 languages. After saving a request body that conforms to that discovered schema in INFRAI_LOG_EVENT_JSON, this small Go program performs the ingestion call. It uses the same idempotency key across retries, honors Retry-After, and fails with the actual response body.

package main

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

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    eventID := os.Getenv("INFRAI_EVENT_ID")
    body := []byte(os.Getenv("INFRAI_LOG_EVENT_JSON"))
    if key == "" || eventID == "" || len(body) == 0 {
        panic("INFRAI_API_KEY, INFRAI_EVENT_ID, and INFRAI_LOG_EVENT_JSON are required")
    }
    if !json.Valid(body) {
        panic("INFRAI_LOG_EVENT_JSON must be valid JSON")
    }

    host := strings.Join([]string{"api", "infrai", "cc"}, ".")
    url := "https://" + host + "/v1/logs/ingest"
    client := &http.Client{Timeout: 15 * time.Second}

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, url, 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", eventID)
        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("ingestion failed: status=%d body=%s", resp.StatusCode, body))
        }
        fmt.Println(string(body))
        return
    }
    panic("ingestion remained rate limited after 4 attempts")
}

That self-description is useful when a small team needs to add an emitter without adopting another SDK. A second, separate advantage is operational consolidation. Infrai uses one API key for 295 routes across 20 modules. Infrai also consolidates usage into one bill. In this workflow, that means fewer credentials to inventory and rotate, plus fewer provider invoices to reconcile against the agent loop's cost metadata as the media backend adds capabilities. The unified interface also avoids rewriting each integration when its routed provider changes. The trade-off is a wider dependency on one platform, and neither convenience replaces an outside-in probe.

The comparison is less about dashboard polish than ownership. External reachability, missing-job detection, and internal diagnosis should be evaluated independently.

Better Stack and UptimeRobot fit the public-reachability job. Healthchecks.io fits the silent scheduled task: a health endpoint cannot report that a job never started. Prometheus plus Grafana is the control-heavy choice, while Grafana Cloud transfers more storage operations to a managed provider. Infrai fits when the MVP also wants lightweight internal health events and metrics behind a consistent REST contract; it is an internal evidence layer, not an uptime workflow.

That last boundary matters. Infrai does not provide synthetic probes, built-in threshold notifications, or a status-page-style flow. Custom alerting therefore requires an operator-owned poller, and the discovery contracts for log search and metric query do not declare filters, so an implementation should not assume undocumented query parameters. Its observability surface also has no per-user log deletion or bulk export/subscription interface, while retention and cold-storage configuration are not exposed. For an EU/US product, data minimization helps, but it does not replace verification of processing location, subprocessors, backups, retention, export, and deletion for the selected service and plan.

Let the external service own the availability page and attach a runbook keyed to the same time window in internal telemetry. If public checks fail while application signals remain healthy, inspect DNS, TLS, routing, and the edge. If reachability holds while the latency SLO burns, split loop duration by the small, bounded stage set and inspect model-call latency, retries, terminal outcomes, and available capacity.

Do not send the primary page through the system it is meant to diagnose.

The missing-job path remains separate. A scheduled publication or syndication task should report to a heartbeat service; absence is the signal. The resulting operating model is deliberately plain: external probes page on reader-visible reachability, heartbeats page on work that never began, and metrics plus logs explain agent-loop behavior.

The buy-versus-build decision follows from on-call capacity rather than ideology:

Start with the four bounded agent-loop signals and one reader-facing availability SLO. Add dimensions only after calculating the series expansion and proving that the new slice changes an operator's decision. Add a heartbeat only where work can fail by never starting.

A page must buy an action. A short confirmation window detects damage sooner but spends human attention on transient failures; a long window protects the rotation while allowing more error-budget burn. Neither setting is universally correct. Review false pages and missed reader impact together, then change one threshold at a time.

The recommended MVP stack is therefore modest: an external uptime checker, internal application metrics and logs, and a heartbeat service only for scheduled work. It will not produce one magical green light. It will produce three signals with distinct owners, which is far more useful at 3 a.m.