Manage Better Stack Uptime: monitors, heartbeats, incidents, on-call calendars and status pages.
Better Stack ships in the w6w first-party pack. It declares 30 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.betterstackBetter Stack Uptime monitors websites, ports, cron jobs and APIs, pages the on-call person when something breaks, and publishes the status page customers read. This app drives that Uptime API from a workflow.
Create, pause, update and delete monitors and heartbeats; read their availability and response times; open, acknowledge, resolve and reopen incidents and read their timelines and comments; look up who is on call and the escalation policies behind them; and read status pages, their resources and their published reports.
Monitor reads are scrubbed: a proxy password, environment variable or Authorization header a user typed into a monitor is redacted before it reaches a workflow’s run record. The Better Stack Telemetry API (logs and metrics) is a separate product and is not part of this app.
Three routes to the same 30 actions. The Workflow tab is generated from Better Stack's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
heartbeat-availability-get Availability summary for a heartbeat over an optional date range.
heartbeat-create Create a heartbeat. The result includes the ping URL for the job to call.
heartbeat-list List the team's heartbeats (cron-job and scheduled-task monitors that ping Better Stack).
heartbeat-update Change a heartbeat's schedule or alerting, or pause/resume it. Only the fields you set are sent.
incident-acknowledge Acknowledge an ongoing incident. The vendor answers 409 if it was already acknowledged.
incident-create Open an incident by hand and alert the on-call person (or an escalation policy).
incident-list List incidents, optionally filtered by date range, monitor, heartbeat, or resolved/acknowledged state. The vendor's default page size is 10 (maximum 50).
incident-resolve Resolve an ongoing incident. The vendor answers 409 if it was already resolved.
incident-timeline-get The incident's timeline: alerts sent, comments, status changes.
monitor-availability-get Availability summary (percentage, downtime, incident counts) for a monitor over an optional date range.
monitor-create Create a monitor. Only the type is required by this app; the vendor rejects combinations that need more (a port for tcp, a keyword for keyword monitors).
monitor-get Fetch one monitor, including its current up/down status. Secrets a user may have typed into it (proxy credentials, environment variables, sensitive request headers) are redacted.
monitor-list List the team's monitors (website, ping, port, keyword and other checks).
monitor-response-times-get Recent response-time samples for a monitor, grouped by check region.
monitor-update Change a monitor's settings, or pause/resume it. Only the fields you set are sent.
on-call-events-list The shifts of one on-call calendar within an optional time window.
on-call-list List on-call calendars and who is on call now. People appear under included[] with name, e-mail and phone numbers.
status-page-resource-list The monitors and other resources shown on a status page, with current status and availability.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Better Stack's real ids.
{
"manifestVersion": "2",
"name": "betterstack-example",
"steps": [
{
"id": "heartbeat-availability-get",
"uses": {
"app": "io.w6w.betterstack",
"action": "heartbeat-availability-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"heartbeat_id": "<heartbeat_id>"
}
}
]
}heartbeat-availability-get escalation-policy-list heartbeat-create heartbeat-get heartbeat-list +25 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Better Stack, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Better Stack. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "heartbeat-availability-get",
payload: {
heartbeat_id: "<value>",
// from: "<value>",
// to: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action heartbeat-availability-get --payload '{"heartbeat_id":"<value>"}' Give an AI agent Better Stack — without giving it Better Stack's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.betterstack#heartbeat-availability-get",
"input": {
"heartbeat_id": "<heartbeat_id>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Better Stack connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Better Stack's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Better Stack itself is MIT, and the runtime that executes it is source-available (FSL).
Better Stack declares its own checks, so its health is a property of the app rather than something the host guesses at.
Component status from status.betterstack.com, limited to the 'Better Stack' and 'Uptime' sections. The 'Telemetry' section is a different product and is ignored.