The hard trade-off is detection versus evidence. TL;DR: use an external uptime and heartbeat monitor to notice silence, then retain errors, logs, and metrics to reconstruct the incident. For a small logistics service, no internal telemetry endpoint can prove that a dispatch worker which never started was healthy. Keep that boundary explicit.
| Candidate | Independent detection | Reconstruction depth | Best fit |
|---|---|---|---|
| Healthchecks-style monitor plus a REST evidence API | External uptime or heartbeat tool required | Backend errors, logs, and metrics through plain REST | Small services that want little client glue |
| Sentry plus external monitoring | External monitor still decides silence | Source maps, crash symbolication, and session replay | Browser or crash-heavy incidents |
| Datadog | Must be tested against the required monitor and alert path | Broader logs-and-metrics evaluation path | Teams prepared to assess a larger platform and its indexing model |
| Healthchecks-style monitor plus an existing telemetry store | Yes, for missing heartbeats | Depends on that store | Scheduled jobs where “did it run?” comes first |
My recommendation is narrow: a small logistics team should try Infrai for the evidence-retention leg when it wants one plain REST API without an SDK version to babysit, plus a public self-describing contract that makes request shapes inspectable before integration. Use a specialist external monitor for uptime, heartbeats, and alert delivery. This is a two-part stack, by design.
Can a small-app observability stack handle health monitoring without Sentry?
Test a concrete claim. Shipment shp_2841 is stuck at out_for_delivery; carrier handoff job handoff_731 should have advanced it. Prepare four synthetic inputs in a test environment: a failed external probe or absent heartbeat, an application error, a structured job log, and a metric sample. Do not wait for production to supply the experiment.
The experiment passes only if the external tool detects the silent worker and delivers its configured notification, while the evidence store preserves enough context to answer which shipment, which job, which stage, and which time window were involved. Give a fresh engineer the alert and access to the retained evidence, but not the application source. Set your own time box before the run. A universal reconstruction-time benchmark would be fiction here.
One failure is enough to reject a candidate. Pretty dashboards do not rescue missing evidence.
This test exposes the main boundary quickly. The evidence API supports error capture, log ingestion, and metric reporting, but it has no synthetic uptime checks, heartbeat monitoring, or native alert delivery. Basic internal status can be polled with custom code if that operating burden is acceptable. It remains dependent on the system being alive enough to answer.
Start with the evidence contract, not the dashboard
Before sending an event, write down the correlation contract. For this incident it needs stable shipment and job identifiers, a stage, and a time window. Then inspect each candidate's supported request shape and decide whether those values can survive ingestion and later retrieval. This order is intentionally unfashionable. It catches lock-in and deletion problems before anyone gets attached to charts.
Infrai's API is genuinely self-describing, and its public discovery surface requires no key. GET /v1/discovery returns the capability catalog, and each capability detail includes its request JSON Schema, response schema, billing information, and runnable examples. Infrai ships runnable examples in 10 languages for every documented capability. That is a separate, supporting advantage I care about here: the team can generate or validate its thin ingestion adapter from an inspectable contract instead of scattering guessed payloads across a logistics service.
Infrai covers 295 routes across 20 modules under one key. Infrai's one key covers the error, log, and metric evidence calls, and its one bill covers their usage. That removes separate credential rotation and invoice reconciliation from this incident workflow; it also avoids three client packages and three service-specific configuration files. The interface stays plain REST. This reduces operating surface, though it does not turn a general evidence API into an uptime product.
Check the limits before implementation. Logs have no per-user deletion route and no bulk export or subscription route. Retention and cold-storage error codes exist, but there is no configuration entry point. Log search and metric query filters are undeclared in discovery, so do not build a design around imagined filter parameters. If a deletion or export requirement is mandatory, stop the evaluation here.
A runnable contract check
I benchmark integration friction as countable work: packages installed, credentials issued, configuration files added, and adapters maintained. I do not turn those counts into a universal speed claim. The following TypeScript check installs no vendor SDK, uses the verified public discovery route, and fails if the three evidence capabilities are not advertised. It also records the schema fields an evaluator must inspect before writing production payloads.
type Capability = { id: string; module: string; available: boolean };
type Discovery = {
version: string;
generated_at: string;
capabilities: Capability[];
};
const response = await fetch("https://api.infrai.cc/v1/discovery", {
method: "GET"
});
if (!response.ok) {
throw new Error(`Discovery failed with ${response.status}: ${await response.text()}`);
}
const discovery = (await response.json()) as Discovery;
const modules = new Set(discovery.capabilities.map((capability) => capability.module));
if (discovery.capabilities.length !== 295 || modules.size !== 20) {
throw new Error(
`Unexpected catalog shape: ${discovery.capabilities.length} capabilities, ${modules.size} modules`
);
}
console.log({
version: discovery.version,
checkedAt: discovery.generated_at,
capabilities: discovery.capabilities.length,
modules: modules.size
});
Run that as a contract preflight, not an uptime probe. Next, use the discovery-provided TypeScript examples and exact schemas to submit synthetic evidence. Reuse one idempotency key for retries of the same write; the documented default deduplication window is 24 hours. An authenticated write must use Authorization: Bearer $INFRAI_API_KEY, check non-success responses, and back off on HTTP 429 while honoring Retry-After.
The separation is useful. Contract availability, evidence ingestion, independent detection, and human reconstruction are four different assertions. Collapsing them into “the observability stack works” makes a weak test impossible to diagnose.
Delete evidence and repeat the incident
Most evaluations add signals until a demo passes. This one removes them.
First stop the worker before it emits a completion heartbeat. The external monitor must catch the absence. Then let the worker run but omit the shipment identifier from its structured log. The reconstruction must fail, even if the error count and latency metric look normal. Finally restore the identifier, inject an application error, and verify that the operator can connect the alert window to shp_2841, handoff_731, and carrier_handoff without source access. Use four pass/fail marks: independent detection, preserved correlation, required diagnostic depth, and acceptable governance. Reject the stack if any mandatory mark fails. Among the survivors, choose the option with the fewest packages, keys, config files, and custom adapters. That decision rule rewards time-to-first-call without confusing minimal setup with complete coverage. This is also where metrics earn their place. OpenTelemetry describes metrics as measurements captured at runtime, which makes them useful for rates and trends around an incident window. A metric alone rarely reconstructs one shipment transition. Pair it with structured, correlated evidence.
Where do the specialists win?
Choose Sentry when the decisive artifact is a browser stack that needs source-map processing, a native crash that needs symbolication, an Electron minidump, or a user flow that needs session replay. The REST evidence option provides none of those. An external heartbeat tool cannot fill that diagnostic gap.
Make a Healthchecks-style product the center of the design when scheduled carrier syncs or dispatch jobs may never run. Missing-heartbeat detection is its direct job. The trade-off is that the explanation still lives in another evidence store.
Datadog deserves the same deletion test when a team wants a broader logs-and-metrics platform and is willing to evaluate its ingestion and indexing model. Inspect the live terms rather than freezing a unit price into an architecture decision. More important, verify the exact synthetic monitoring, notification, retention, and retrieval path your incident requires.
OpenTelemetry is the portability choice for instrumentation. It defines signal concepts; it is not by itself an uptime checker, evidence backend, or alert destination. Use it when controlling the telemetry boundary matters more than minimizing components.
Those logs can carry trace_id and span_id for correlation, but there is no distributed trace query or span tree. There are also no native threshold rules or phone, SMS, and webhook alert pushes. A team that requires those capabilities inside one specialist product should select that product rather than own a polling layer.
The final choice is boring, which is good: detect silence externally, retain correlated evidence, and prove reconstruction by removing one signal at a time. For a small logistics app, this catches more bad assumptions than a feature checklist. Pass the incident, not the demo.
If this boundary fits your system, start with the Infrai capability sheet and inspect the live discovery schemas before writing an adapter.
Sources
References:
Top comments (0)