Better Stack Integration Guide: Where Incident Toil Still Lives

Your phone buzzes at 3:07 a.m. You acknowledge the page in forty seconds. You know which of your services is actually broken forty minutes later. Everything in between — scrolling monitor lists, grepping deploy channels, opening log tabs — is toil, and it happens on every single incident.

That gap is what this Better Stack integration series is about. Better Stack is a genuinely good stack: uptime checks from multiple regions, heartbeat monitors for cron jobs, on-call schedules with escalation policies, log aggregation, and status pages, all under one roof. Detection and paging are solved problems. But between "a human has been paged" and "the incident is resolved," almost everything is still manual — and that manual middle is where on-call hours actually go.

This guide maps the five places incident toil survives even a well-configured Better Stack setup: what each one looks like, why it persists, how to spot it in your own account today, and what it typically costs in minutes per incident. This is part one of a three-part series. Part two is a hands-on guide to squeezing everything out of Better Stack's native automation — monitors, escalation policies, webhooks, and the Uptime API. Part three covers closing the investigation gap with AI agents.

1. The 3 a.m. context hunt

What it is. The page tells you that something is down, not why. A monitor named api-prod-eu fails its check from three regions; the alert contains the URL, the HTTP status, and the response time. It does not contain which service sits behind that endpoint, which of the four deploys that shipped yesterday touched it, whether the database failed over an hour ago, or whether this is the same thing that happened two Tuesdays back. The responder rebuilds all of that context by hand, half-asleep, before they can form a first hypothesis.

Why it happens. Monitors accumulate faster than documentation. A team running 50–100 monitors rarely maintains a current map from monitor → service → owner → runbook, because that map goes stale with every rename and every migration. So the map lives in the heads of two senior engineers, and the context hunt is longest exactly when someone else is on call.

How to spot it. Pull your recent incidents from the Uptime API and look at the gap between acknowledged_at and resolved_at:

curl -s "https://uptime.betterstack.com/api/v2/incidents?per_page=50" \
  -H "Authorization: Bearer $BETTERSTACK_API_TOKEN" |
  jq -r '.data[].attributes | [.name, .started_at, .acknowledged_at, .resolved_at] | @tsv'

Acknowledgment is typically fast — under two minutes if your escalation policy works. If resolution routinely lands 30–60 minutes later even for incidents whose eventual fix was one command, the difference is context hunting, not fixing.

Typical cost. 20–40 minutes per real incident, concentrated in the responders least familiar with the failing service. On a team with 8–12 incidents a month, that's a working day of pure orientation.

2. Heartbeat monitors nobody wired up

What it is. Better Stack's heartbeat monitors are built for the things that fail silently: cron jobs, backup scripts, queue consumers, certificate renewal jobs. The job pings a unique URL on every successful run; no ping within the expected period plus grace time, and you get paged. It's an excellent feature — for the jobs that are actually enrolled. The failure mode is the nightly PostgreSQL backup that has been exiting non-zero for three weeks, discovered the day you need the backup.

Why it happens. Heartbeats require someone to create the monitor and modify the job to ping it. Uptime monitors get created when a service launches, because downtime is loud. Scheduled jobs get written, verified once, and forgotten, because their failure is silent by definition. There is no forcing function.

How to spot it. Count your heartbeats and compare against the crontabs and scheduled workflows you actually run:

curl -s "https://uptime.betterstack.com/api/v2/heartbeats" \
  -H "Authorization: Bearer $BETTERSTACK_API_TOKEN" |
  jq -r '.data[].attributes | [.name, .period, .status] | @tsv'

Then, on a representative host or in your scheduler: crontab -l, your Kubernetes CronJob list (kubectl get cronjobs -A), and your CI's scheduled pipelines. Most teams doing this audit for the first time find they're monitoring fewer than half of their scheduled jobs.

Typical cost. Zero minutes per incident — until it's an incident, at which point it's the worst kind: data loss or a compliance gap measured in days or weeks of undetected failure, not minutes.

3. Log search happens in a different tab than the incident

What it is. Better Stack ships log management (Telemetry) alongside Uptime, which should make incident investigation seamless. In practice, the incident page and the log explorer are still two tabs and one human copy-paste apart. The responder reads started_at off the incident, switches tabs, sets the time range by hand, types a query from memory, realizes they filtered the wrong service, and starts over.

Why it happens. The incident knows the monitor; the logs know the service; only the responder knows the join between them. Without per-service saved views and consistent structured fields (service, env, request_id), every incident's log search is improvised. A query like this is quick to run — once you know it's the right one:

level:error AND service:checkout-api AND host:prod-eu-*

How to spot it. An honest ten-minute audit: open your last five incidents and ask whether a saved log view existed for the affected service with the right filters, or whether the responder built the query live. If your Telemetry sources aren't tagged so that a monitor name maps cleanly to a log filter, the answer is already no.

Typical cost. 10–20 minutes per incident of query iteration and time-range fiddling — more when logs from the relevant service turn out not to be shipped at all, which is its own unpleasant 3 a.m. discovery.

4. Incident timelines assembled by hand, after the fact

What it is. The postmortem asks: what happened, when, who did what, what fixed it. Better Stack records detection, acknowledgment, escalations, and resolution automatically — but the investigation itself happened in Slack threads, terminal scrollback, a Grafana tab, and someone's memory. So the day after, an engineer reconstructs the timeline by scraping all four sources into a doc.

Why it happens. During the incident, nobody is taking notes; the person who knows the most is the person busiest fixing it. The tooling captures the lifecycle of the incident, not the investigation.

How to spot it. Compare a recent incident's resolved_at timestamp with the timestamp on the finished postmortem document, and ask the author how long the writeup took. A 25-minute outage that takes 90 minutes to document is the norm, not the exception — which is also why postmortems quietly stop happening for "small" incidents, and the same small incident recurs quarterly.

Typical cost. 60–120 minutes per documented incident, paid in daytime engineering hours; or, if skipped, paid later as repeat incidents.

5. Status page updates under pressure

What it is. Better Stack status pages can reflect monitor state automatically — the red bar shows up on its own. Human-written updates ("we've identified the cause, ETA 20 minutes") do not. Under pressure, the responder's priorities are, in order: fix it, keep the internal channel updated, and then remember the status page. Customers experience a red bar with no words on it, and route around it: twenty minutes in, support is fielding duplicate tickets asking whether you know you're down.

Why it happens. Writing a public update requires calm judgment — what to say, what not to promise — exactly when the author has none to spare. So it waits, or falls to whoever feels guilty first.

How to spot it. In your Better Stack dashboard, open Status pages and review the last few status page reports against the underlying incident timestamps. Measure detection-to-first-update. If it's over 10 minutes, or if incidents resolved without any prose update at all, your customers noticed.

Typical cost. 5–10 minutes of responder attention per update — cheap — plus a support-ticket spike and customer-trust cost that's harder to measure and larger.

The pattern: paging is solved, investigation isn't

Add it up and a "45-minute incident" costs three to four engineer-hours: the context hunt, the log spelunking, the writeup, the status page follow-through. None of that is Better Stack's failure. Uptime monitoring automation and on-call escalation are the parts of incident response that tooling has genuinely solved — the alert fires within seconds, the escalation policy finds a human within a minute or two, reliably, at any hour.

What remains manual is the middle: correlating the alert with what changed, reading the logs against the timeline, forming and testing a hypothesis, keeping the record. Escalation delivers a human quickly; it then hands that human all of the work. Part two of this series pushes Better Stack's native features — monitor tuning, escalation policies, webhooks, the Uptime API, log alerts — as far as they'll go on exactly this problem. It's worth doing, and it has a ceiling.

Shrink the manual middle

The investigation itself can be automated. CloudThinker connects to Better Stack via OAuth in about two minutes, read-only by default. When an incident fires, CloudThinker agents pull the failing monitor's context and recent logs, investigate the infrastructure behind the endpoint, and post a likely cause with evidence — so the paged human arrives to a diagnosis, not a blank timeline. Escalation stays intact; nothing changes without your configured approval level. Try CloudThinker free — 100 premium credits, no card required — or continue with the hands-on native-tools guide.