InBrief

Using InBrief

InBrief runs hosted status pages with uptime monitoring and multilingual incident communication. Every tool acts on the connected user's own InBrief account.

What this connection can reach

• Only the tools and status pages the user approved when connecting. Anything else returns ACCESS_DENIED. Ask the user to widen the connection in InBrief (Settings → MCP connections) instead of retrying.
• The user's current role and the account's MCP policy apply to every call.
• A status page created through this connection is not added to it. The user has to approve that page in InBrief before page tools can use it.

Common workflows

• Report an outage: find the page and the affected services, publish an incident with its status and impact, post updates as things change, then resolve it. A postmortem can be drafted and published afterwards.
• Plan maintenance: schedule the window with the affected services. It can be updated or cancelled before it starts, and completed once the work is done.
• Check health: read monitor status, the public status summary and uptime history before answering questions about availability.

Actions the user finishes in InBrief

Sensitive tools start a review instead of making the change: team changes, API keys, webhooks, billing and subscriptions, subscriber exports, deleting a page or the account, and outage-page code. They return a link. Nothing changes until the user opens it, confirms who they are and approves. Don't report these as done because a link came back.

Good habits

• List pages, monitors or incidents to get IDs instead of guessing them.
• Incidents, maintenance and templates change against their current revision. Read the latest version first. If it changed in the meantime, read it again and retry.
• When a tool takes an idempotency key, retry an interrupted call with the same arguments and key.
• Publishing or updating an incident or maintenance can notify the page's subscribers. Agree the wording and affected services with the user first.