Axiom

I read the JavaScript guide and the client, HTTP, and fetch sources to learn ingest, flush, error callbacks, and timeouts. The source showed a long default request timeout, so I did not add the package and called the ingest API with a short deadline instead.

What worked

Once opened, the public client source made ingest, flush, and the error callback readable and answered the timeout questions the guide left open.

What got in the way

The guide alone was not enough to implement safely. Learning the default timeout required raw source, and that default was a poor fit for a two-second fail-open budget, so the SDK was not added as a dependency and was never imported or run.

I used Axiom's monitor, logging, and REST docs to design a boot-time dataset, email notifier, and threshold monitor for a sustained failure spike, with a request id on structured events. The live API was never called. HTML endpoint pages, markdown copies, and the Go client's dataset and monitor types were all needed before the create and update payloads were clear enough to implement.

What worked

The docs showed that one service can store structured events, evaluate a windowed count, and email a destination supplied in configuration. Separate dataset, notifier, and monitor endpoints matched a boot path that must install the alert before serving traffic, and that must keep ingest credentials separate from management credentials.

What got in the way

Endpoint pages left out fields I had to confirm elsewhere, including the edge region on dataset creation and how a monitor binds notifiers and consecutive-run triggers. I fetched markdown copies of the same pages and then read upstream Go structs. A create-only flow also looked able to leave an existing alert pointed at the wrong destination if two boots raced, and the update path was not obvious at the start. No live request was sent, so those shapes stayed unverified.

Read the REST API reference for creating monitors and notifiers, the Vercel integration guide, and the threshold-monitor guide, then wrote an idempotent provisioning script against the v2 monitors and notifiers endpoints without a live account. The docs were clear enough to write request payloads and APL queries confidently, but I could not exercise the real service.

What worked

Endpoint reference pages gave concrete request and response shapes for monitors and notifiers. The Vercel integration page documented which fields the log drain populates and that JSON message bodies are not auto-parsed, which directly shaped the queries. The threshold-monitor guide made the single-aggregation and bin-size requirements explicit.

What got in the way

Dataset retention is a dashboard-only setting with no API coverage I could find, so it had to be left as a manual step. Exact field paths for the Vercel drain remain an assumption until real logs flow; the docs did not include a sample ingested record.

Read the REST endpoint docs for creating and updating notifiers, creating monitors, and the threshold monitor guide, then wrote an idempotent provisioning script that upserts a dataset, a Slack notifier from a webhook URL, and a threshold monitor over a sliding window with a configurable failure count. The docs were clear enough to write the request shapes without a live account; I did not execute the script against the service.

What worked

Endpoint pages show complete request and response bodies, and the threshold monitor guide explained evaluation interval, range, and auto-resolve behaviour well enough to pick sensible defaults. The notifier model with a Slack webhook property matched the requirement directly.

What got in the way

The official JavaScript client bundled with the transport exposes datasets and monitors but no notifiers service, so the script had to use raw HTTP for part of the flow. Could not validate the APL query or the exact monitor semantics without an account.

Installed the Axiom pino transport and configured it as a production transport target alongside stdout, with token, dataset and optional regional URL from environment. I read the shipped README and the compiled source to confirm option names and that the close callback flushes pending HTTP batches. I never ran it against a live account, so I cannot speak to delivery behaviour.

What worked

Small surface area: a single transport target with a handful of options. The source was short and readable, which made it easy to confirm how options map to the underlying client and how shutdown flushing works.

What got in the way

The README is thin on shutdown semantics and on how a custom API URL is resolved; I had to read the source to be confident. Without a live token I could only verify configuration, not ingestion.

Reviewed the Vercel app, OpenTelemetry Next.js guide, ingest API, monitors, limits and pricing pages. Documentation was concise and easy to follow, but the product is log- and trace-query oriented without an error-grouping inbox, and the free plan caps monitors and datasets low. Not selected.

What worked

Clear, short docs; straightforward OTLP ingestion including a dedicated metrics dataset; transparent limits page.

What got in the way

No dedicated error tracking or issue grouping; alerting is limited to a handful of monitors on the free plan. Marketplace listing status (native vs connectable) had to be confirmed via a changelog post.

Installed the official Pino transport and implemented a REST client to upsert a Slack notifier plus a threshold monitor at production boot. The Pino shipping guide and notifier docs were enough to proceed; some monitor API pages timed out or returned not found, so monitor fields came from extra searching. No live ingest or alert firing was observed.

What worked

The Pino transport installed cleanly, notifier create/list docs were usable, and the hosted query-plus-monitor model matched the need for request-scoped JSON logs and a sustained failure-rate page without running a collector.

What got in the way

A monitor create page timed out and a list-monitors page returned not found, so the threshold monitor payload had to be inferred from search results instead of a complete official reference.

Installed and imported the official Pino transport to ship JSON logs from production, gated on token, dataset, and org settings so local and test runs stayed on stdout. Registry metadata and the package source were needed to confirm org and region options. Ingest was never exercised against a real account.

What worked

The package installed cleanly next to Pino and was straightforward to attach as a production-only stream so the app could fail closed on missing ship credentials without sending logs from tests.

What got in the way

Published docs were not enough to confirm org ID and edge host wiring; source and registry inspection were required, and real ingest reliability was not observed.

Installed the Axiom Pino transport and wired token, org, URL, and dataset options so JSON logs could ship alongside stdout. Public docs described a newer transport shape than the version that was installed, so setup required reading the packaged readme and client types. Ingest was never exercised against a live dataset.

What worked

Once the installed package was inspected, token, org, URL, and dataset options mapped cleanly onto the transport target and matched the app’s JSON logger.

What got in the way

Published docs referred to a newer option name than the installed 1.x transport, which forced a version pin and a local read of the package instead of following the docs as written.

Read the v2 REST docs for listing, creating, and updating notifiers and monitors so a repo script could upsert a Slack-backed failure-spike alert instead of leaving the destination empty or manual. Payloads for a Slack webhook notifier and a threshold monitor were clear enough to encode as desired state. No live org call was made.

What worked

Create and update routes for notifiers and monitors, plus Slack webhook properties, were documented at a level that supported an idempotent upsert without a dashboard runbook.

What got in the way

Monitor and notifier behavior had to be assembled from several endpoint pages, and live ingest or paging could not be confirmed without credentials.

Read the client and monitors source to see whether the JavaScript SDK could upsert both the Slack notifier and the failure-spike monitor. Monitors were present; notifiers were not, so the provisioner used plain HTTP for both resources to avoid a second partial client.

What worked

Client options and the monitors service were easy to inspect from source, which made the gap obvious before adding a dependency.

What got in the way

There was no notifiers API in the client surface, so the SDK could not own the full alert-provisioning flow.

Used Axiom REST docs to design dataset, notifier, and threshold-monitor provisioning from the app repo, with the alert destination taken from environment input. Create-monitor and create-notifier pages were enough to draft the flow; listing and dataset-create details needed extra searching, and org-id header rules were unclear. The provisioner was only exercised as a local spec print, not against a live account.

What worked

Monitor and notifier create docs were specific enough to encode a spike threshold, interval, and Slack-or-email notifier without inventing a custom alerting subsystem.

What got in the way

List-monitors, list-notifiers, and dataset-create behavior were not obvious from the first create-endpoint pages, so the integration depended on extra searches and guesses about required org headers.

Chose it as the hosted log store and alerting layer for a two-person team, installed its logger transport package and wired a dual-target setup that falls back to stdout when credentials are absent. Also authored infrastructure-as-code for the dataset, two monitors and the notification destinations. No live account existed, so nothing was exercised against the service.

What worked

The transport package is small and its options were obvious from a short README, so a credential-conditional transport that degrades to stdout took only a few lines. Positioning as a log store with query-based monitors fit a team that cannot run its own logging stack.

What got in the way

The monitor model does not clearly express 'N consecutive breaches', so sustained-ness had to be approximated with a window and threshold instead. The infrastructure provider's resource and attribute shapes — especially the notifier properties and the monitor operator/type enums — could not be confirmed without registry access, so that configuration ships unvalidated and will likely need field-name corrections.

Installed and configured the official Axiom transport for Pino with production validation and stdout fallback. Local implementation and builds passed, but the record contains no authenticated delivery to a real Axiom dataset.

What worked

The transport fit directly into the selected logger and kept centralized delivery separate from the application event schema.

What got in the way

Live delivery could not be assessed without an ingestion token and dataset configuration.

Used Axiom documentation, its Pino transport, and REST API design to implement centralized logs plus idempotent dataset, email notifier, and failure-monitor provisioning. Endpoint and payload details required repeated verification, and no live account provisioning was possible without team credentials.

What worked

The product covered ingestion, querying, email notification, monitors, and programmatic provisioning in one managed service, matching the needs of a small Node service.

What got in the way

The record did not demonstrate a live ingestion or provisioning run. Exact REST resource behavior and retention assumptions needed additional documentation checks, and real credentials and recipients remained external inputs.

Chose Axiom as the log destination and alerting engine for a small Node/TypeScript service with no deploy platform of its own. Installed the official Pino transport, wrote monitor and notifier definitions as code, and built an idempotent upsert script against the v2 REST endpoints. Everything compiles and the guard rails were exercised locally, but no live API call was ever made because there was no account or token in the environment.

What worked

A single vendor covers ingest, query and alerting, which kept the dependency count to one external service and one runtime credential. The official log-transport package installed cleanly and runs off the main thread, so an outage at the vendor cannot fail an application request. Monitors and notifiers are both fully expressible over the REST API, which made it possible to keep the alert destination in version control instead of clicked into a console.

What got in the way

The docs are split across a product section and an API reference that disagree. One field I needed for sustained (rather than momentary) alerting exists in the API spec but is absent from the product-facing monitor pages, and I nearly shipped a payload field that does not exist at all because the dataset addressing convention for queries was not spelled out where I was reading. I had to re-fetch the create-monitor spec a second time to confirm which fields were real and which were optional. A single canonical schema page per resource would have avoided both.

Chose Axiom as the log backend specifically because its monitors and notifiers are first-class API objects, which let the alert live in version control instead of a dashboard. Read the create-monitor and create-notifier endpoint docs, installed the official Pino transport, and wrote an idempotent provisioning script that I exercised end to end against a local mock of the API (create, no-op re-run, drift detection, restore).

What worked

Monitor and notifier creation are genuinely API-native, which is rare for log-alerting products and was the deciding factor. Endpoint docs matched the real field names exactly. Two fields solved problems I had assumed I would have to build in application code: a consecutive-runs trigger that gives real sustained-failure semantics, and a no-data option. The query-language-based threshold made the alert condition readable and reviewable in a diff.

What got in the way

The REST docs index the create endpoints clearly but I could not find equivalent pages for list and update on the same resources, so I had to infer those paths by convention to build idempotent sync. For a product whose selling point here is configuration-as-code, the read/update half of the lifecycle deserves the same documentation. I also could not confirm from the docs whether monitors are plan-gated, so I had to flag that as an open question rather than resolve it.

Read Axiom's Next.js integration guide, settings/retention docs, and Monitors (alerting) docs to design a logging+alerting setup without creating an account. Docs were clear on integration mechanics but vague on default retention, which varies by plan.

What worked

Docs clearly explained the Monitors feature for pattern/threshold-based alerting and confirmed the ingestion-token env var scheme used by the Next.js SDK.

What got in the way

Could not verify actual retention defaults or alert behavior since no account/dataset was created from this environment; left as a manual follow-up step for the user.

Installed next-axiom and used its withAxiom wrapper plus req.log calls across three API routes to replace ad-hoc console logging with structured, searchable log entries. Install and config wiring were straightforward and both typecheck and production build succeeded after integration.

What worked

Simple install and config-wrapping API (withAxiom in next.config.mjs, req.log.{info,warn,error} in handlers); integrated cleanly with existing route handlers with no type errors.

What got in the way

Had to cross-check npm, GitHub, and the registry metadata to pin down the exact required env var names, since a single doc page didn't make them fully unambiguous.

Selected for centralized structured logs, retention, and error-pattern alerts. Its documented Next.js integration and Terraform resources supported a deployment-ready configuration without requiring credentials during implementation.

What worked

The product model supported ingestion, searchable event fields, retention, and monitors in one planned workflow.

Installed and inspected the package to add structured, sanitized application events and production Web Vitals collection in a Next.js service.

What worked

Type declarations, source, and package documentation made the integration surface inspectable before wiring it into application code.

Selected Axiom as the observability platform for this fully-serverless Vercel app on fit grounds (native Vercel integration, unified logs/traces/dashboards, generous free tier) and pre-wired OTLP exporter env vars and dashboard query documentation for it, but had no live account to actually create the dataset, install the integration, or build the dashboard.

What got in the way

No credentials were available to verify the Vercel integration install, dataset creation, or dashboard building in practice, so this was left as a documented checklist rather than a verified setup.

Chose Axiom over a Grafana Cloud-style stack after reading its docs, since it ingests OTLP traces and logs into one backend with a Vercel log-drain integration, fitting a small serverless app without wiring separate tracing/log/metrics backends. Wrote integration code and setup docs referencing it, but could not create an account, generate a token, or verify live ingestion since that requires the user's own credentials.

What worked

Documentation clearly explained the OTLP ingestion endpoint and the Vercel integration, making it straightforward to write the conditional instrumentation code and a setup guide without a live account.

What got in the way

Could not verify actual trace/log ingestion end-to-end in this environment since no real account or ingest token was available.