How to use a Righthand with Better Stack

Quick answer

Use Righthand to prepare a Better Stack incident handoff from monitor evidence and accepted notes. Keep detection, investigation, recovery, and communication separate.

Start with a reviewable deliverable, keeping Better Stack as the accepted home for its records. This guide uses an explicitly approved snapshot or browser read; it does not assume that every provider API action is exposed by your Righthand connection.

Evidence and access

Better Stack documents uptime monitoring and incident workflows. See the official Better Stack reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved monitor and incident packet, including monitor IDs, checks, timestamps, acknowledgment history, and owner-confirmed resolution evidence. Verify the required tools and owner-approved scope through Righthand integrations; use the supplied packet when a native read is unavailable.

Define the objects and authority

Include these fields in the working input: monitor ID, incident ID, start time, current status, response evidence, owner, related log reference. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A monitor recovery does not prove every customer task recovered. Publishing updates and changing monitoring require separate permission.

Illustrative first-run brief

Use the owner-provided Better Stack snapshot or approved read-only view. Review the supplied incident timeline for one service. Identify unanswered availability questions and missing customer checks. Prepare a handoff without resolving or publishing. Run once for the agreed sample, using America/Los_Angeles for the review deadline and preserving source timestamps separately. Return the draft in this conversation by Friday at 3 PM Pacific for the incident commander to review. Include source references and missing fields. Do not write records, spend money, change permissions, or send external messages. Stop and report an unavailable source rather than substituting another account.

Expected result and verification

The packet can show a recovered endpoint while an affected workflow remains unverified. It retains that open check.

Compare the timeline to monitor events and one approved application-level check. Record the source cutoff, applied filters, and items excluded from the sample. The reviewer should be able to follow each consequential finding back to an original object. A well-written summary is not evidence that a proposed action happened. If a later write is authorized, verify its specific result separately before changing the task's status.

Illustrative input and draft output

These synthetic entries show the requested review, not live account results or a provider field schema.

Common failure and recovery

A check can target a cached page or different region. Ask the operator to verify the intended endpoint and geography before closing the incident.

If status-page text and monitor state conflict, preserve both and ask the incident owner to validate the customer-facing update.

FAQ

What should the reviewer verify first?

Verify monitor target, check window, incident identity, and result evidence. Acknowledgment means someone engaged with the incident; it is not the same as recovery.

How should a repeat run be scoped?

Retain monitor IDs and incident chronology between reviews. Recheck resolution evidence and communication state separately; avoid copying a prior outage's conclusion into a new incident.

For connection and permission details, use Righthand Docs. Review Pricing alongside any separate provider charges before expanding the workflow.