get_resource_standby

Read the standby kept for one resource — its health, whether posts are mirrored into it, and when it was last probed and written to.

Purpose

A standby is a spare channel or group the bot already administers, linked to one resource so a ban can be answered by a swap. This reads it: health_status (with the connector's health_reason code when degraded), mirror_enabled, health_checked_at, last_mirrored_at, linked_at. The standby's own identifier on the platform is deliberately absent. The REST twin is GET /v1/projects/{project}/resources/{resource}/standby.

Required ability

project-recovery:view

Input schema

{
    "type": "object",
    "required": [
        "resource_id"
    ],
    "properties": {
        "resource_id": {
            "type": "string",
            "description": "UUID of the resource whose standby to read."
        }
    }
}

Output shape

{
    "data": {
        "resource_id": "b73c5f21-9d80-4a6e-8215-4f70ce13a9d6",
        "mirror_enabled": true,
        "health_status": "healthy",
        "health_status_label": "Healthy",
        "health_reason": null,
        "health_checked_at": "2026-09-12T02:00:00Z",
        "last_mirrored_at": "2026-09-12T01:45:12Z",
        "linked_at": "2026-09-01T14:22:09Z"
    },
    "meta": {}
}

Example prompts

"Is the standby for Signals healthy and mirrored?"

Failure modes

  • RESOURCE_NOT_FOUND — the resource keeps no standby, or resource_id is not a resource the token can see.
  • AUTHENTICATION_REQUIRED — no authenticated user on the request.
  • TOKEN_MISSING_ABILITY — token lacks project-recovery:view.

How is this guide?

On this page

Subscriby is a product designed by you — for you.

No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request