Skip to main content
Better Stack is an uptime monitoring, incident management and log management platform. This connector extracts the operational record behind it: the monitors and heartbeats that watch your services, every incident they raised and how long it took to acknowledge and resolve it, the availability figures Better Stack computes, the on-call schedules and escalation policies that decide who gets paged, the public status pages you publish, and the configuration of your telemetry sources and collectors.

​
1. Add your Better Stack access

  1. In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Better Stack option from the list of connectors.
  2. Click Next and you’ll be prompted to add your access.
    • API token: required. In Better Stack, go to API tokens and copy a token from the Global API tokens section. A global token is the right choice for a pipeline: it covers every team and both the Uptime and Telemetry products, so no table is left out.
    • Start date (advanced): earliest date to read incidents and on-call shifts from. Leave empty to start from the oldest data Better Stack still serves. Every other endpoint returns its full contents on each sync, so this setting does not affect the other tables.
    • Incidents lookback (days) (advanced): how far before the last synced incident to re-read on each run. 30 by default.
    • Page size (advanced): records requested per page. 250 by default, which is Better Stack’s maximum.
    • Requests per minute (advanced): how fast the connector is allowed to call the API. 300 by default.
A team-scoped Uptime API token also works, but it only reaches one team’s Uptime resources. The four telemetry_* tables cannot be read with it and will stay empty. Use a global token unless you deliberately want to limit the source to a single team.
  1. Click Next.

​
2. Select your Better Stack streams

  1. The next step is letting us know which streams you want to bring. You can select entire groups of streams or only a subset of them.
    Tip: The stream can be found more easily by typing its name.
Four streams cost one request per parent record — monitor_availability and monitor_response_times per monitor, heartbeat_availability per heartbeat, telemetry_source_metrics per telemetry source. On an account with hundreds of monitors they make the sync noticeably longer, so select them only if you need them.
  1. Click Next.

​
3. Configure your Better Stack data streams

  1. Customize how you want your data to appear in your catalog. Select a name for each table (which will contain the fetched data) and the type of sync.
  • Layer: companies in the Growth plan can choose in which layer the tables with the extracted data will be placed.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: depending on the data you are bringing to the lake, you can choose between INCREMENTAL and FULL_TABLE. Read more about Sync Types here.
  1. Click Next.

​
4. Configure your Better Stack data source

  1. Describe your data source for easy identification within your organization. You can inform things like what data it brings, to which team it belongs, etc.
  2. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times).
  3. Optionally, you can define some additional settings (if available).
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.

​
Check your new source!

  1. Click Next to finalize the setup. Once completed, you’ll receive confirmation that your new source is set up!
  2. You can view your new source on the Sources page. Now, for you to be able to see it on your Catalog, you have to wait for the pipeline to run. You can now monitor it on the Sources page to see its execution and completion. If needed, manually trigger the pipeline by clicking on the refresh icon. Once executed, your new table will appear in the Catalog section.
If you encounter any issues, reach out to us via Slack, and we’ll gladly assist you!

​
Before you rely on the data

monitor_response_times cannot be backfilled. Better Stack keeps individual check timings for the last 24 hours only and offers no date filter on them, so this table builds up history from your first sync onwards. Schedule the pipeline to run at least once a day, or the series will have gaps that nothing can recover.
A few behaviours are worth knowing before you build on these tables:
  • Only incidents can sync incrementally. It is the one Better Stack endpoint that accepts a date range. Every other table is read in full on each run, which is why almost all of them are FULL_TABLE.
  • Incidents keep changing after they start. An incident’s started_at never moves, but acknowledged_at and resolved_at are filled in later. The connector re-reads the last 30 days before the bookmark on every run so those updates land; raise Incidents lookback (days) if incidents in your account often stay open for longer than that.
  • The availability tables are rollups, not history. monitor_availability and heartbeat_availability hold lifetime figures that Better Stack recomputes on every call, so each sync replaces the previous answer. To keep a time series of your SLA, snapshot the table with a History.
  • Join incidents to monitors through monitor_id. The connector lifts it out of the API’s relationships object into its own column. It is empty for incidents raised by an integration or an incoming webhook rather than by a monitor.
  • Severities are called urgencies in the API. Better Stack renamed the concept in the product but kept the old name on the wire, so severities and severity_groups come from the urgencies endpoints. The type column still reads urgency.
  • Nested data arrives as JSON text. Fields with sub-structure — an incident’s metadata, a policy’s steps, a status page resource’s status_history, a catalog record’s attributes — are stored as JSON strings. Read them with JSON_VALUE(column, '$.field') in your queries.
  • team_members mixes people and invitations. A row is an accepted member when type is team_member and a pending invitation when it is team_member_invitation; invitations carry invited_at instead of created_at.
  • Credentials are not extracted. The heartbeat ping URL, a telemetry source’s ingest token, a collector’s secret, an escalation policy’s incident token and a monitor’s basic-auth password, environment variables and Playwright script are all write credentials, which have no place in a warehouse table.
  • Log lines and metric points are out of scope. Better Stack serves them through a separate ClickHouse-compatible query API that runs SQL over your retention window. The telemetry tables here describe where your telemetry comes from and how it is shaped, not the events themselves.

​
Available streams