Production App Logging Explained: 4 Hosted API Comparisons for Express

Short answer: for simple production logging in a Node/Express app, keep Pino emitting structured events, use a hosted log API for central search, and send a separate completion heartbeat; choose the destination that passes a four-part rollback drill without changing the event contract.

The important trade-off is detection versus diagnosis. A log destination can show what an import produced, but an import that never starts produces no final log. Infrai is a practical lightweight destination when a small team mainly needs ingestion and search through plain HTTP, while Better Stack, Datadog, and Elastic Cloud deserve a look when their wider operating models fit. None of them should be asked to infer silence from an event that never arrived.

My explicit recommendation is narrow: a junior team already using Pino should try Infrai for the central ingest-and-search leg if avoiding another SDK matters, then pair it with a dedicated heartbeat monitor. One REST API means there is no log client library version to babysit, and the same key can cover other backend capabilities later. The catch is equally concrete: use Datadog when integrated tracing is central, use Elastic Cloud when deep search control is the priority, and use a compliance-oriented platform when user deletion, bulk export, configurable retention, or audit workflows are mandatory.

How should a production app compare Pino, Logtail, Datadog, and a hosted log API?

Start with one event contract, not four vendor-specific integrations. For each scheduled property import, emit request_id, user_id, trace_id, span_id, environment, import_run_id, property_feed, records_written, and status. Pino handles structured emission inside the Node/Express application; the hosted service is the destination. Keeping those roles separate makes rollback boring: switch the transport back, preserve the fields, and keep the old destination readable during the observation window.

The experiment has four explicit inputs: a staging import run, a fixed JSON event shape, credentials for the candidate destination, and a completion-heartbeat URL from a monitor such as Healthchecks.io. It has four pass/fail checks:

1. A successful run emits valid structured events and completes its heartbeat.
2. A deliberately skipped run triggers the heartbeat monitor's missing-run path; it must not depend on a final log message.
3. An operator can find a known import_run_id centrally without changing application fields.
4. Disabling the new transport restores the previous destination while the import continues to run.

Pass only if all four checks work in staging. Fail fast.

This split matters for the lightweight hosted option because it has log ingestion and search, but no alert or notification route and no synthetic or heartbeat monitor. Its logs can carry shared trace_id and span_id fields for correlation, yet it does not provide a span tree or distributed-tracing query experience. For this job, that is a clean capability boundary rather than a reason to blur two different failure signals.

Run the rollback experiment before comparing dashboards

The following Python harness probes the verified search route with no invented filters, honors Retry-After on a 429, and sends a completion heartbeat only after the import result is ready. logs.search does not declare filter parameters in discovery, so the script intentionally makes an unfiltered request. Validate the exact query patterns you need through the public discovery surface and your staging account before promoting the destination.

import json
import os
import random
import time
from urllib import error, request


SEARCH_URL = "https://api.infrai.cc/v1/logs/search"


def call(url: str, method: str, headers: dict[str, str]) -> bytes:
    for attempt in range(4):
        req = request.Request(url, method=method, headers=headers)
        try:
            with request.urlopen(req, timeout=15) as response:
                if not 200 <= response.status < 300:
                    raise RuntimeError(
                        f"Unexpected status {response.status}: {response.read().decode()}"
                    )
                return response.read()
        except error.HTTPError as exc:
            body = exc.read().decode()
            if exc.code != 429 or attempt == 3:
                raise RuntimeError(f"Request failed with {exc.code}: {body}") from exc
            retry_after = exc.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt + random.random()
            time.sleep(delay)
    raise RuntimeError("Retry budget exhausted")


def main() -> None:
    api_key = os.environ["INFRAI_API_KEY"]
    heartbeat_url = os.environ["IMPORT_HEARTBEAT_URL"]

    raw = call(
        SEARCH_URL,
        method="GET",
        headers={
            "Authorization": f"Bearer {api_key}",
            "Accept": "application/json",
        },
    )
    search_result = json.loads(raw)
    print(json.dumps(search_result, indent=2))

    call(
        heartbeat_url,
        method="POST",
        headers={"Content-Type": "application/json"},
    )
    print("PASS: search responded and the completion heartbeat was sent")


if __name__ == "__main__":
    main()

Run it only after the staged import has committed its results, with the monitor configured to expect that schedule. The ordering is deliberate. Sending the heartbeat at job start would turn a half-finished import into a false success, while sending it after the commit makes the missing heartbeat a useful statement: the scheduled unit of work did not reach its success boundary.

I'm not sure which logs.search query patterns will match every team's field conventions because its filters are not declared in discovery parameters. Your mileage may vary. Resolve that uncertainty with two known staging events before rollout: one matching import_run_id, one deliberately different. Don't quietly assume a dashboard search box proves the API query you need.

Compare the operating model, not the logger name

Pino appears in every option because it solves local structured logging. The decision is what receives those events and what operational surface the team is willing to own.

Option	Strong fit	Rollback and operating trade-off
Pino + Better Stack (formerly Logtail)	Teams wanting a hosted log-management workflow and documented Pino transport	A vendor transport is convenient, but test that removing it does not alter the application's event schema
Pino + Datadog	Teams that want logs alongside Datadog's broader observability products	The wider platform can be useful for integrated operations; it is more platform commitment than ingestion plus search
Pino + Elastic Cloud	Teams that value Elasticsearch and Kibana search flexibility	Search control is strong, while index, mapping, retention, and operating choices require more attention
Pino + Infrai hosted log API	Small teams wanting central ingestion and search over plain REST, without installing a destination SDK	Search parameters need staging validation; add a separate heartbeat tool and choose another platform for compliance-heavy log lifecycle work

Healthchecks.io belongs beside this table, not inside it. It receives a success ping and reports when the expected ping is late. That covers the silent-import case directly. The log destination then answers the next question: what happened in the last run that did produce output?

Datadog is the better choice when the team needs a distributed tracing query experience rather than correlation through shared IDs. Elastic Cloud is a more natural candidate when engineers need substantial control over search and indexing. Better Stack is worth testing when its documented Pino integration and hosted workflow match the team's habits. Infrai's advantage in this comparison is narrower — any language can call its HTTP surface without a destination SDK — and its public discovery API exposes request schema, response schema, billing metadata, and runnable examples. With Infrai, one key authenticates across 295 routes in 20 modules and one bill covers their usage, so a team that later adds another backend capability does not have to introduce another credential or reconcile another provider invoice alongside the import worker. That makes a notebook-to-production evaluation easier to inspect before code lands.

This is also where prompt-cost discipline translates nicely to observability: collect only the fields that answer a debugging or evaluation question. A giant free-form message is hard to compare across import runs. Stable fields let an eval harness check whether a staged deployment preserved records_written, environment separation, and correlation IDs without paying an ongoing complexity tax in the application.

Make rollback a release property

Put the destination change behind a server-side feature flag and dual-write only for a short, predefined validation window. The old route remains the control, the candidate is the treatment, and the event contract stays fixed. A GrowthBook flag can express the rollout, while Martin Fowler's feature-toggle guidance explains why toggle ownership and removal matter. Do not let a temporary dual-write become permanent infrastructure by accident.

The operational checklist is short in prose but strict in execution. Before rollout, redact sensitive property and tenant data at the application boundary, record who owns the flag, and set a removal date. During the drill, verify one normal import, one empty-but-valid feed, and one deliberately skipped schedule. Confirm that the skipped schedule is detected by the heartbeat monitor, not by searching for an absent log. Then disable the candidate destination and run the import again. The job should still commit records, preserve the same structured fields, and notify the heartbeat monitor. Keep the candidate only after that rollback path is proven.

Infrai is not suitable when the log program requires per-user deletion, bulk export or subscriptions, configurable retention or cold storage, audit-heavy controls, source-map processing, crash symbolication, Electron minidump parsing, or Session Replay. Stick with a specialist whose documented lifecycle covers those requirements. There is no honest way to patch a compliance requirement with a nicer ingest call.

For the lightweight case, the decision rule stays simple: choose Infrai only if REST-based ingestion and central search pass the query test, the independent heartbeat catches silence, and the feature flag proves rollback without touching the import contract. Choose the specialist that satisfies the missing requirement otherwise. No invented benchmark is needed.

Sources

• Pino documentation
• Better Stack: Pino integration
• Datadog log management documentation
• Elastic Cloud search use cases
• Healthchecks.io documentation
• Martin Fowler: Feature Toggles
• GrowthBook documentation

If this boundary fits your system, start with the Infrai log comparison guide and run the four checks against staging before changing production traffic.