How to use a Righthand with Statuspage

Quick answer

Use Righthand to prepare a Statuspage incident-update draft using verified facts and approved affected components. Keep public communication separate from technical recovery decisions.

Start with a reviewable deliverable, keeping Statuspage 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

Atlassian documents Statuspage incident fields, affected components, and subscriber notification choices. See the official Statuspage reference. Provider capabilities and Righthand's available tools are separate checks.

Use the approved page's component and incident history with page ID, public or internal audience, update timestamps, and owner-confirmed customer 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: incident ID, status, message, affected component, observation time, reviewer, notification choice. These are the requested review columns, not a promise that every provider endpoint returns them under those exact names.

A public statement can create expectations. The communications owner approves wording, component impact, and whether notifications are sent.

Illustrative first-run brief

Use the owner-provided Statuspage snapshot or approved read-only view. Draft an update from the approved incident brief. Separate confirmed impact, ongoing investigation, and the next update window. Do not publish or notify subscribers. 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 communications lead 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

An unconfirmed cause remains under investigation instead of appearing as a factual explanation. A resolved status needs approved recovery evidence.

Compare each impact statement and component selection with the incident owner's accepted facts. 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

Old incident templates can imply recovery prematurely. Replace unsupported wording and ask for current evidence before proposing resolution.

If a draft update refers to the wrong component or audience, hold publication review and ask the communications owner to correct the scope.

FAQ

What should the reviewer verify first?

Verify page and component identity, incident chronology, update wording, and approved audience. Posted recovery language should have supporting evidence from the responsible owner.

How should a repeat run be scoped?

Retain incident IDs, component mappings, and update times. Refresh factual status before each separately authorized publish; a previous approved update may no longer describe current behavior.

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