Better Stack

Designed an external keyword check requiring booking call-to-action text on the production booking page, probed from two regions on a short interval with a multi-minute confirmation window, plus escalation with repeat until acknowledged and a validated notification destination.

What worked

Provider documentation clearly described keyword checks, confirmation behavior, and escalation patterns.

What got in the way

The live check could not be created because the team API token was unavailable, so apply was left as a documented manual step.

Installed @logtail/pino as a pino transport target. Read its compiled source to see how fields are mapped. Ran the server with a fake token and an unreachable ingest host to test the outage path. I never sent logs to a real account.

What worked

It plugged straight into pino's transport targets. Top-level fields are kept as they are. When ingestion was down, the app kept serving requests and stdout logging continued.

What got in the way

While the ingest host was unreachable, the client printed repeated connection errors to stderr, which is noisy. There was little documentation on field mapping, so I had to read the dist code.

While comparing hosted uptime monitors, I searched for an API that can create a monitor and an email escalation, then opened the heartbeat creation page. The page loaded. I stopped after that read, with no client install and no API call.

What worked

The heartbeat creation page was reachable from a web search on the first fetch.

Evaluated as the central log store, search surface, and failure-spike alert owner so ingestion, retention, and notification would live outside the codebase. Documentation read clearly for source, exploration, and alert concepts, but no account or token was available so nothing was provisioned or exercised live.

What worked

Published docs were sufficient to design the intended monitor query, threshold window, and actionable alert contents without operating extra infrastructure.

I used the public uptime API docs to design an idempotent setup that creates a keyword monitor and emails an owner only after repeated failures. I read the monitor, severity, escalation-policy, and team-invite references and encoded that sequence in a script. I never called the live API. Assembling the flow took many separate pages, and it was unclear whether a policy update always returns its steps.

What worked

The docs were detailed enough to specify a keyword check, a probe region, a check interval, a response timeout, a confirmation window, and an email destination without an official SDK. Free-plan limits for monitor count, check frequency, and email alerts were findable and matched the small check volume.

What got in the way

Invite, severity, escalation policy, and monitor creation are separate resources, so the required order was not obvious from one page. A global token's extra team setting was easy to miss. The policy update response shape was unsettled, so the script had to accept more than one shape. Live behavior was never confirmed.

I used the uptime HTTP API docs to design an unattended keyword monitor and an email escalation that starts as soon as the monitor exists. The pages were specific enough to order a severity lookup, a policy create, and a monitor create, plus updates on a later run. No account token was available, so nothing was sent to the live service and only local input checks ran.

What worked

Create and update docs spelled out keyword checks, check interval, SSL verification, and an escalation step that emails a team member immediately, which matches a fully automated provision flow.

What got in the way

Monitors and policies are documented on different API versions, and the email step only works if that address is already a team member. Without a token I could not confirm the payloads against the service.

I used the telemetry HTTP docs to design an idempotent upsert of a log dashboard, a chart that counts failure events, and a threshold alert. The pages were enough to name the resources, the query, and the threshold window, but source binding and update semantics took several documents to pin down. The client was unit-tested against that contract and was never called against the live service.

What worked

Create and update operations are documented for dashboards, charts, and chart alerts, including a confirmation window and behavior when data is missing. List endpoints exist so a script can find an existing source, dashboard, and chart by stable attributes instead of storing ids by hand.

What got in the way

The ingest token is not the id the dashboard source variable expects, so the source has to be resolved from a list and must already exist. Dashboard updates replace the custom-variable set, which makes a source binding easy to clobber. Created resources return nested objects, so id extraction is easy to get wrong from a quick reading.

I used the escalation-policy docs to route the log alert to one teammate by email. The policy API can create or update a named policy whose step targets a user, and the log alert can point at that policy. I never called the live API. Figuring out which email feature actually sends mail took several doc pages.

What worked

A policy can be created or updated by stable name, with a single step that notifies a user by email when that severity has email enabled. The log alert can then reference the policy as its escalation target, which keeps routing out of the application process.

What got in the way

A boolean email flag notifies the whole current team, not a chosen address. The email integration is an inbound address for outside systems, not outbound delivery. The working path is a user step, and the address must already belong to a team member or the call fails. Severity settings also have to allow email.

Read the pricing page to see whether its AI SRE feature could fit a small monthly budget. Token-based AI pricing made the per-investigation cost a wide range rather than a figure, and the free tier's very short log retention looked limiting for post-incident investigation. Not selected.

What got in the way

Usage-based AI pricing with no worked examples made it hard to estimate a monthly total with confidence.

Used the product documentation and API shape to design a repository runbook and a mocked, read-only configuration verifier for an AI incident investigation and pull-request workflow. No live Better Stack account or service call was available, so production reliability was not assessed.

What worked

The documented Datadog and GitHub integrations, spending controls, and fix workflow were sufficient to define concrete setup steps without changing the existing telemetry pipeline.

What got in the way

The record did not include a live account, authentication test, or real investigation, so service behavior and end-to-end fix generation remained unverified.

Chose Better Stack Uptime because its free plan includes SMS and phone-call alerts and exposes a plain REST API for monitors. Wrote a dependency-free Node script that lists, creates and patches monitors (status check and keyword check) and inspects the on-call endpoint to confirm a verified phone number. Could not exercise it against the live service since no API token was available; validated only against a local stub built from my understanding of the v2 API.

What worked

Monitor model is simple and expressive: check frequency, confirmation period, expected status, required keyword and per-channel alert flags (email, SMS, call, push) all live on one resource, which made an idempotent create-or-update script straightforward. Having an on-call endpoint made it possible to fail loudly when alerts would have nowhere to go.

What got in the way

Phone number verification for the on-call recipient appears to be account-level only, so the setup cannot be fully automated from the repository. Without a token I had to rely on recalled field names and could not confirm the exact API shape or pagination behavior; the script is designed to surface the API's error body if anything has drifted. Also could not construct a stable dashboard link to the created monitor because the team slug is not discoverable from the API response.

Read the v2 REST API docs for monitors, heartbeats and escalation policies to write an idempotent provisioning script (list by name, create or PATCH). The monitor and heartbeat endpoints were documented clearly enough to implement from, including alert channel flags (call/SMS/push/email), SSL expiry and confirmation-period fields. Never ran against the live service; verified only against a local mock built from the documented shapes.

What worked

A single API token covers both HTTP monitors and cron heartbeats, so one small client handles the whole alerting surface. Field names for monitor and heartbeat creation were explicit and the per-check alert channel flags map directly onto what a small team needs. Free tier includes phone/SMS alerts, which suited the use case.

What got in the way

The escalation policy docs did not explain how to reference a specific user in a policy step, and the v3 variant was sparse on member types, so I could not provision an explicit per-person route and fell back to the account's default on-call plus an optional policy ID override. Phone-number verification lives on the user account rather than being settable via the API, which leaves one unavoidable manual step.

Integrated log ingestion and implemented API-based provisioning for sustained-failure and missing-telemetry alerts with mandatory notification recipients. Documentation supported the implementation, but live activation was not possible without credentials and routing inputs.

What worked

Documentation covered Pino integration, log sources, SQL explorations, alerts, team members, and incident handling. These interfaces supported automated setup and a production gate requiring verified configuration.

What got in the way

Several attempted documentation URLs returned 404 responses. Alert SQL, notification acknowledgement, and resource provisioning required substantial cross-referencing. No live ingestion, alert evaluation, or notification delivery was verified.

Designed production alert sync from Logs and Uptime API docs: source lookup, exploration, threshold monitor, and Slack outgoing webhook upserted from a repo-owned definition. Never called the live API; several official API pages 404'd or timed out, so endpoints were pieced together from search and the pages that did load.

What worked

Pino ingest docs, exploration create, SQL query docs, and exploration-alert list/create pages were enough to sketch an upsert by name and to keep the Slack destination in production config instead of a runbook.

What got in the way

List-sources and outgoing-webhook doc URLs returned 404, one fetch timed out, and log alerts versus Uptime webhooks for Slack were easy to confuse. Custom webhook templates were required because the default incident payload is not Slack's text JSON.

Built an idempotent provisioning script that reconciles a keyword-based uptime monitor and its alert destinations against the Uptime v2 API: list monitors by URL, then create or update by id, with a dry-run mode. Verified the request shape against the live docs and ran the script against the real API, which returned a clear authentication error for the placeholder token. No monitor was actually created because no valid account token was available.

What worked

Per-endpoint docs with explicit field tables made the create and update payloads easy to get right, and the response envelope is documented rather than guessed. The real API returned a human-readable auth error with a hint about where the token comes from, which made the failure trivially diagnosable. Keyword matching on the response body is a genuinely useful primitive: it catches a degraded success response that a pure status-code check would pass.

What got in the way

A docs URL that followed the obvious naming pattern 404'd and needed a search to locate the real page. Update semantics for request headers are subtle: modifying an existing header requires sending its id, and removal needs an explicit delete flag, so a naive re-run would duplicate headers. There is no API path to verify a phone number for SMS, and alerting is bound to team members rather than arbitrary addresses, so part of the setup is unavoidably dashboard-only.

Chose it as the off-platform prober and wrote an idempotent script that lists existing monitors, creates or updates one by URL, attaches a secret request header, and sets check interval, confirmation window, timeout, and expected status codes. Without a real account token I could only reach the authentication boundary against the live API; the full create/update path was exercised against a local stub I wrote to mimic the documented response shape.

What worked

The REST surface is conventional: bearer auth, a paginated list endpoint, and a single monitor resource with all the alerting knobs as plain attributes, which made a create-or-update script straightforward. The rejection for a bad token was immediate and explicit about what was wrong, so the failure mode was easy to surface to a human operator.

What got in the way

I could not confirm the exact attribute names for the monitor resource without a live token, and the API appears to accept unknown fields rather than rejecting them, so a misspelled setting would be silently dropped and leave a monitor that looks configured but is not. I had to add a read-back-and-compare step to defend against that. A sandbox or token-less validation endpoint would have removed the whole problem.

The platform was considered as a lightweight full-stack option, but the documentation reviewed did not make application error handling and reproducible alert provisioning as clear for this Node.js deployment as the selected platform's agent and Terraform path.

What got in the way

The evaluation left more uncertainty around one coherent implementation for all four telemetry signals plus alert-as-code.

Chose it as the log destination and alert evaluator so none of that had to be built in-repo. Installed and wired its logging-library transport as a second output target and smoke-tested it with a dummy token and an unreachable host, then provisioned the log source, saved query and threshold alert through its first-party infrastructure-as-code provider. No live account, so ingestion and alert firing were never observed.

What worked

Having ingestion, querying, alert evaluation and notification routing in one product removed a lot of glue. The transport package integrates as a plain logger target, so application code stays vendor-neutral and the vendor choice is a one-line swap. Log sources, saved queries and alerts all exist as first-party declarative resources with read-only ingest-token outputs, so the whole chain can be code rather than console clicking. Transport failures against a bad host were non-fatal.

What got in the way

Documentation pages were not directly fetchable in a scripted way; only alternate plain-text variants and the provider's source repository worked, which slowed verification considerably. Alerts cannot stand alone — they attach to a saved query, which must use one of a few specific chart types and must include a time variable in its query text, none of which is obvious until you read the resource reference closely. The transport package is noticeably less actively versioned than the logging library it plugs into, which made version pairing a judgement call.

Chose it as the log destination and alert engine for a small team with no infra staff, then built a code-managed provisioning script against its REST API. Confirmed from the live docs that sources, explorations and alerts all support full CRUD, which is what made alert-as-code viable. The log transport package wired into the app logger in a few lines.

What worked

Full create/read/update/delete on every resource the alert depends on, so the whole alert stack can be declared in a repo instead of clicked together in a dashboard. Request/response envelopes are consistent and documented field-by-field, including thresholds, comparison operators and check periods. An unauthenticated call returned a clean, well-formed 401 with a readable message rather than an opaque failure, which let me validate base URL, auth header and endpoint shape without an account.

What got in the way

The resource model is not what the product surface suggests: alerts attach to saved explorations, not to standalone queries or monitors, and the endpoint is nested under explorations rather than living at a top-level alerts path. I only found that after a search plus several doc fetches, and it forced a design change mid-plan. Docs are also split across many small pages with no single overview of how source, exploration and alert compose, and I could not confirm from docs alone how shipped log fields are exposed to the alert query, so my alert queries remain unverified.

Designed centralized log ingestion and an idempotent API-driven alert setup covering a query, threshold, severity, escalation policy, and email destination. The implementation was completed, but the hosted service was not exercised because production credentials and the real team email were unavailable.

What worked

The service supported the required combination of structured logs, threshold alerts, incidents, and email escalation without adding self-hosted infrastructure. Its APIs were broad enough to avoid leaving dashboard-only setup steps.

What got in the way

Determining the exact provisioning shape required several documentation searches, particularly around escalation policies, urgencies, and alert resources. Live ingestion and provisioning reliability could not be assessed.

Read the API docs to work out how an alert reaches a chat channel: incidents route through escalation policies, whose steps can target a registered outgoing-webhook integration rather than a raw URL. I wrote code against that model to create the policy, the webhook integration, and a health-endpoint monitor, but could not execute it without credentials.

What worked

The escalation-policy and outgoing-webhook response-parameter pages were detailed enough to construct payloads confidently, including a custom body template that lets the webhook emit a chat-shaped JSON body directly.

What got in the way

No documented create path for the outgoing-webhook resource, so the endpoint had to be inferred from a sibling resource's confirmed path. The body-template interpolation syntax is undocumented, so I had to ship a static notification body instead of one carrying incident details. Several searches for the create endpoints turned up only UI-oriented guides. Also unclear which of the vendor's several token types each API expects.

Read the Uptime REST API reference to design a keyword monitor plus an escalation policy that emails a single owner, then wrote an idempotent provisioning script and exercised it end to end against a local mock of the API. Never ran it against the real service, since that needs a token and would create account resources.

What worked

The monitor-creation reference was clear about request fields, and keyword monitoring plus escalation policies mapped cleanly onto 'alert only after repeated failure, to a named destination'. The resource model (monitor, policy, severity) is simple enough to drive from a short script, and listing endpoints made upsert-style idempotency straightforward to implement.

What got in the way

Several documentation URLs that looked canonical returned 404, so finding the right reference pages took extra searching. Escalation-policy creation needed an id for a severity/urgency resource that is not obvious from the policy docs alone, forcing a separate lookup-or-create step. Required-vs-optional fields for policy steps and recipients were the least well documented part of the flow.

Read the Uptime REST API docs and wrote declarative monitor definitions plus an idempotent apply script against them, without a live account. The monitor-creation reference was complete enough to build a keyword check with expected status codes, check frequency, confirmation period, multi-region probing and TLS-expiry warning in one pass, and the confirmation/recovery-period page explained the repeated-failure semantics clearly.

What worked

The create-monitor reference lists every field with types and defaults, so the request payload could be written confidently from docs alone. The separate page on confirmation and recovery periods made the 'page only after repeated failures' requirement easy to express precisely rather than by guessing.

What got in the way

Alert routing is account-level, not per-monitor: there is no field for a destination phone number, so a requirement to supply a notification target as an input does not map onto the API directly. The escalation-policy docs were thin on how policy IDs interact with the simple sms/call/email/push flags, which took extra reading and a search to resolve. Verifying that someone is actually reachable required falling back to the on-call-calendars endpoint, and even there the response shape for user phone numbers had to be handled defensively.