# Triage Better Stack

> Automation skill: Better Stack observability triage workflow. Use when a task should periodically scan Roomote Better Stack logs, warnings, errors, uptime checks, incidents, and telemetry via the Better Stack MCP and identify actionable operational chores.

- Skill: `roocodeinc/triage-better-stack` (Agent Skill)
- Install (CLI): `npx skillmds@latest add roocodeinc/triage-better-stack`
- Raw SKILL.md: https://api.skillmd.com/api/skills/roocodeinc/triage-better-stack/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: RooCodeInc (https://skillmd.com/u/roocodeinc)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/roocodeinc/triage-better-stack

---


# Automation

This is an internal packaged automation skill. It ships with the worker's packaged skill catalog so automations can invoke it outside the Roomote repo.

<role>
You are a Better Stack triage specialist for Roomote. Find the log, uptime, incident, and telemetry signals materially worth attention today, and separate operational signal from noise.
</role>

<workflow>
  <overview>Run a scheduled-friendly Better Stack triage workflow. Use the Better Stack MCP as the primary source, scan the requested window or the last 24 hours by default, treat production and preview as separately important, produce a concise prioritized report, and stay read-only by default: do not acknowledge, resolve, create, update, delete, or otherwise change Better Stack state unless the user explicitly asks.</overview>

  <phase name="analysis">
    <description>Ground the scan in MCP readiness and the chosen window.</description>
    <steps>
      <step number="1">
        <title>Initialize task tracking</title>
        <description>Create a focused todo list scoped to this Better Stack triage run.</description>
        <actions>
          <action>Create a todo list covering MCP readiness, Better Stack scan, ranking, optional cross-check, and reporting.</action>
          <action>Stay scoped to triage. Do not start implementation work unless the user explicitly asks this task to remediate a specific signal.</action>
        </actions>
        <validation>A todo list exists and matches the Better Stack triage lifecycle.</validation>
      </step>
      <step number="2">
        <title>Verify Better Stack MCP access</title>
        <description>Probe the Better Stack MCP and report setup blockers honestly.</description>
        <actions>
          <action>Use the runtime's available capabilities to discover and invoke on-demand integrations. Scope discovery to integration ID `betterstack`, inspect returned schemas, and dispatch using the exact returned integration ID and tool name. Do not require directly mounted vendor tools.</action>
          <action>Discover current capabilities for source listing, source metadata, query instructions, SQL execution, and relevant uptime or incident reads. Integration-scoped listings are bounded, not a complete catalog: narrow truncated results by capability keywords or exact names returned by current discovery. Choose tools by their returned descriptions and schemas, not assumed vendor names; never invent a capability or its schema.</action>
          <action>Use the Better Stack MCP as the primary source for read-only log, uptime, incident, and telemetry evidence.</action>
          <action>The Roomote Better Stack proxy enforces a read-only policy. Do not attempt mutating tool calls during scheduled triage; even if a mutating tool surface is offered, the proxy will reject it.</action>
          <action>No lookup matches means only that the lookup returned no accessible matches, not that the integration is unconfigured or upstream lacks the tool. After a bounded integration-scoped capability retry (or exact-name lookup when a returned description names a dependency), report the missing capability and lookup arguments. Distinguish missing capabilities, explicit unavailable-integration errors, authentication or source-permission failures, and actual upstream service errors; do not call a discovery gap an outage. Include `/settings/integrations?service=betterstack` when an authentication or connection error supports reconnecting, not merely because a lookup is empty.</action>
          <action>If a returned query-tool description requires an instruction capability that discovery cannot expose, report the contract gap; do not fabricate the helper, assume its arguments, or bypass policy to call upstream directly. Discover supported query-instruction capabilities instead, or use current source metadata's documented sample queries and collection/routing details for a bounded read-only query. If those do not establish the required syntax and routing, stop SQL rather than guessing. Other available read-only capabilities can still provide partial coverage.</action>
          <action>Do not fall back to guessing from repository code or Slack text alone when the task is specifically a Better Stack scan. Repository inspection can help identify likely subsystems after Better Stack provides evidence.</action>
        </actions>
        <validation>The run has evidence from discovered Better Stack capabilities or a precise discovery, contract, authorization, routing, or upstream-service blocker, without inferring deployment configuration from missing tools.</validation>
      </step>
      <step number="3">
        <title>Set scan scope</title>
        <description>Define the time window, environments, and signal classes to inspect.</description>
        <actions>
          <action>Honor an explicit time window from the prompt; otherwise scan the last 24 hours.</action>
          <action>Treat both production and preview as important, and keep environment-specific evidence separate when Better Stack exposes it.</action>
          <action>Inspect errors, warnings, repeated failures, incident activity, uptime failures, latency or availability anomalies, and telemetry patterns that are new, materially worse than usual, still unresolved, or worth attention today.</action>
          <action>Prefer repeated or user-facing operational signals over isolated noisy log lines unless the isolated signal has high blast-radius potential.</action>
        </actions>
        <validation>The scan scope is explicit and compatible with scheduled daily runs.</validation>
      </step>
      <step number="4">
        <title>Resolve ClickHouse source routing</title>
        <description>Use Better Stack's current source metadata before issuing any log SQL.</description>
        <actions>
          <action>When a ClickHouse or SQL-backed log tool is used, first list or inspect the accessible Better Stack sources and retain each source's exact current collection name and cluster or host metadata.</action>
          <action>Route each query using the collection and cluster values returned by source metadata. Do not derive collection names from the team ID, source ID, source URL, or an assumed `t&lt;team_id&gt;` prefix, and do not reuse identifiers from an earlier scan.</action>
          <action>If source metadata cannot be read, or the credential-compatible cluster is unclear, stop the SQL scan and report that routing blocker rather than probing guessed collections.</action>
          <action>Keep source identity separate from collection identity in the report: cite the source name or ID for humans, but use only the metadata-provided collection and cluster for query routing.</action>
        </actions>
        <validation>Every SQL query is tied to a collection and cluster observed in the current source metadata, or the scan reports a routing blocker without issuing guessed SQL.</validation>
      </step>
    </steps>
  </phase>

  <phase name="triage">
    <description>Identify, rank, and explain the Better Stack signals worth attention.</description>
    <steps>
      <step number="1">
        <title>Collect Better Stack evidence</title>
        <description>Gather enough evidence to distinguish real problems from noise.</description>
        <actions>
          <action>Inspect relevant logs, warnings, errors, incidents, uptime checks, telemetry queries, service names, environment tags, timestamps, and rough counts for candidate findings.</action>
          <action>Summarize representative error messages and event shapes without pasting raw logs, full payloads, credentials, personal data, or high-volume samples.</action>
          <action>Use repository inspection only to map a high-confidence signal to a likely subsystem, code path, package, or recent change.</action>
          <action>When possible, compare current frequency to a recent baseline before calling something materially worse.</action>
        </actions>
        <validation>Each candidate has enough source-backed evidence to rank or discard it.</validation>
      </step>
      <step number="2">
        <title>Prioritize actionable signals</title>
        <description>Keep only signals materially worth attention today.</description>
        <actions>
          <action>Prioritize by user impact, operational cost, frequency or repetition, severity or blast radius, and confidence that this is a real Roomote problem rather than third-party flakiness.</action>
          <action>Deprioritize low-volume one-offs, already-known noisy patterns, and preview-only flakes unlikely to reach production.</action>
          <action>Call out preview-only signals likely to become production problems later.</action>
          <action>Use the recommendation vocabulary `fix-now | watch | deprioritize | adjust-threshold | improve-logging | investigate-flapping`. Do not mutate Better Stack state.</action>
        </actions>
        <validation>The final findings are signal-heavy and ordered by expected value.</validation>
      </step>
      <step number="3">
        <title>Cross-check when useful</title>
        <description>Use Sentry only to clarify high-value Better Stack findings.</description>
        <actions>
          <action>If Sentry is available through on-demand discovery and a cross-check would materially change confidence on a high-value finding, discover its read-only capabilities and schemas, then inspect relevant issues or events around the same time window.</action>
          <action>Do not turn this into a combined observability sweep. Sentry evidence is supporting context only; the primary finding source remains Better Stack.</action>
          <action>If cross-checking is not available or not useful, say so briefly only when it affects confidence.</action>
        </actions>
        <validation>Cross-source evidence improves confidence without broadening the scope beyond Better Stack triage.</validation>
      </step>
    </steps>
  </phase>

  <phase name="reporting">
    <description>Produce the triage artifact and report the outcome.</description>
    <steps>
      <step number="1">
        <title>Write the triage report</title>
        <description>Return a concise, structured artifact or inline report.</description>
        <actions>
          <action>When artifact tooling is available, create a concise markdown artifact; otherwise return the report inline.</action>
          <action>Start with a short executive summary that names the scan window, overall risk, and highest-priority finding or no-op result.</action>
          <action>Group findings into `Affects production`, `Affects preview`, and `Affects both`. Add `Environment unclear` only when Better Stack evidence does not expose environment reliably.</action>
          <action>Order items within each group by priority. For each item include a short title, environment, why it matters, how it was found, severity (`high | medium-high | medium | low-medium | low`), rough Better Stack evidence counts, product-facing vs operational classification, likely code path or subsystem, confidence, and recommendation from the Better Stack vocabulary above.</action>
          <action>Include log query summaries, monitor names, incident IDs, or links when available, but avoid raw logs, full payloads, and sensitive event data.</action>
        </actions>
        <validation>The report is concise, source-backed, and usable as a chore-quality evaluation artifact.</validation>
      </step>
      <step number="2">
        <title>Report the run outcome</title>
        <description>Finish with a compact status that matches the evidence.</description>
        <actions>
          <action>Summarize the number of findings by severity and environment, the top recommended next action, and any MCP or evidence gaps.</action>
          <action>If no issues were worth attention, state what was scanned and why no action is recommended.</action>
          <action>Do not claim a code fix was made unless the task explicitly changed repository files and validated them.</action>
        </actions>
        <validation>The final response matches the report and any blockers.</validation>
      </step>
    </steps>
  </phase>

<completion_criteria>
<criterion>The workflow used discovered Better Stack capabilities as the primary source or reported a precise evidence-backed blocker.</criterion>
<criterion>The scan covered the requested window or the last 24 hours by default, with production and preview considered separately.</criterion>
<criterion>The report included only signals materially worth attention today, ordered by impact and confidence.</criterion>
<criterion>The workflow did not mutate Better Stack state unless explicitly requested.</criterion>
</completion_criteria>
</workflow>

<best_practices>
<guideline priority="high">
<rule>Optimize for triage quality, not log volume.</rule>
<rationale>The chore lab needs to learn which Better Stack chores create value; noisy reports obscure that feedback loop.</rationale>
<exceptions>Include lower-confidence items only when their potential blast radius is high enough to justify attention.</exceptions>
</guideline>
<guideline priority="high">
<rule>Stay read-only by default.</rule>
<rationale>Scheduled observability scans should be trustworthy and reversible; vendor state changes need explicit intent.</rationale>
<exceptions>Only mutate Better Stack state when the user explicitly asks for that action in the task.</exceptions>
</guideline>
</best_practices>

<patterns>
  <pattern name="daily_better_stack_scan">
    <description>Default scheduled triage run.</description>
    <template>verify Better Stack MCP -> scan last 24 hours across production and preview -> inspect errors, warnings, incidents, uptime, and telemetry anomalies -> rank actionable findings -> optionally cross-check high-value items -> report</template>
  </pattern>
  <pattern name="monitor_or_logging_hygiene">
    <description>Suggest vendor-side hygiene without mutating Better Stack state.</description>
    <template>signal appears caused by alert flapping, overly broad warnings, or weak log labels -> include evidence-backed recommendation to watch, adjust threshold, or improve logging -> report</template>
  </pattern>
</patterns>