Status pages

A status page is a public page you control: a list of components with a status each, public incidents with their updates, and scheduled maintenance. Your agent edits it through MCP or the CLI. Everything it edits is a draft. Nothing reaches the public page until you deliberately publish it, or a component you opted in to automatic updates changes status.

There is no status-page editor in the Console. The public page itself is a separate page, rendered outside the Console, and it stays: anyone with the link can read it.

Ask your agent

"Create a status page with the slug acme-status and components for the API, the web app and the checkout. Preview the public document and show me before you publish."

"Post a public update on the checkout incident: we have identified the cause and are monitoring."

Job	MCP tool or action	CLI command
Create a draft page	create_status_page	anectico status-pages create
List pages or read one draft	list_status_pages, get_status_page	anectico status-pages list, anectico status-pages get <page-id>
Change the title or description	update_status_page	anectico status-pages update <page-id>
Add, change or remove a component	define_status_component, set_status_component_status, delete_status_component	anectico status-pages component put <page-id> <component-key>, anectico status-pages component delete <page-id> <component-key>
Open, update or remove a public incident	create_status_incident, update_status_incident, delete_status_incident	anectico status-pages incident create <page-id>, incident update <page-id> <incident-id>, incident delete <page-id> <incident-id>
Announce, change or remove maintenance	create_status_maintenance, update_status_maintenance, delete_status_maintenance	anectico status-pages maintenance put <page-id>, anectico status-pages maintenance delete <page-id> <maintenance-id>
Preview what a publish would write	preview_status_publication	anectico status-pages preview <page-id>
Publish or take the page down	publish_status_page, unpublish_status_page	anectico status-pages publish <page-id> --yes, anectico status-pages unpublish <page-id> --yes
Read publications	list_status_publications	anectico status-pages publications <page-id>
Serve the page on your own subdomain	claim_status_domain, verify_status_domain, remove_status_domain	anectico status-pages domain claim <page-id>, domain verify <page-id>, domain get <page-id>, domain remove <page-id>
List or remove email subscribers	list_status_subscribers, remove_status_subscriber	anectico status-pages subscribers list <page-id>, anectico status-pages subscribers remove <page-id> <subscription-id>
Delete a page	delete_status_page	anectico status-pages delete <page-id> --yes

The scopes are in Permissions. The MCP write tools preview first and apply on a second call with a confirm_token; see MCP tools.

What your agent gets back

A page read returns the draft: its components, public incidents with their updates, maintenance and its publication state. list_status_pages also says whether the draft has changes that are not published yet. A preview returns exactly the public document a publish would write, with its size against the limit. A publication read returns the revision, the origin (manual or automatic), the state and any refusal.

Open the proof

A status page has no proof page. Its proof is the public page itself: open the public address after the publication reaches published. Everything on it is public, so check it as a stranger would see it. The page does not show data from your workspace beyond the fields listed in the next section.

Draft vs. published

Every edit — a new component, a status change, an incident, a maintenance window, even the page's title — changes the draft. The draft is private: only people with access to your workspace can read it, through your agent or the CLI. Publish takes a snapshot of the current draft and puts it on the public page. Editing the draft again afterward changes nothing public until you publish again.

The public document is built from an explicit, narrow list of fields. Only a component's key, name, group and status; a public incident's title, impact, status, affected component names, and its public updates; and a maintenance's title, text, affected components and time window are ever published. Nothing else about your workspace — internal ids, who made a change, an internal incident this public one describes, or an association with a monitor or a service — is ever part of the public document, no matter what you name things.

Create a page

Ask your agent to create a page. A page needs:

• a slug — its permanent public address (3-48 characters: lowercase letters, digits and hyphens, starting and ending with a letter or digit). A slug can never be reused for a different page, even after you delete the one holding it, so a link to your status page never ends up pointing at somebody else's content;
• a title; and
• an optional description.

Once you have published at least once, the page is public at its Anectico address. A custom domain serves it on your own subdomain instead. The page's public_url is part of the custom-domain read.

Edit the title or description

Read the current draft and its revision with GET /api/v1/status-pages/{pageId} or anectico status-pages get <page-id>. Then send PATCH /api/v1/status-pages/{pageId} with that positive revision as expected_revision and the fields you intend to change. For example, when the current revision is 7, this changes only the description and keeps the title:

{"expected_revision":"7","description":"Service availability and planned maintenance"}

Omitting title or description, or setting it to JSON null, keeps its current value. Sending "description":"" explicitly clears the description. A supplied title cannot be empty or contain only whitespace. A request with neither non-null field is rejected with HTTP 400; it does not advance the draft revision.

The CLI follows the same rules: omitted flags keep their fields, and --description "" clears the description. These are alternative examples; replace <current-revision> with the revision you just read, and use the new revision after each successful edit:

anectico status-pages update <page-id> --revision <current-revision> --title "Service status"
anectico status-pages update <page-id> --revision <current-revision> --description "Availability updates"
anectico status-pages update <page-id> --revision <current-revision> --description ""

You can also supply both fields together. Every successful edit returns the updated draft and its new revision. It does not publish the page or change the currently published snapshot. If someone edits the draft concurrently, HTTP 409 STATUS_REVISION_CONFLICT means your revision no longer matches. The refusal names the revision observed at the comparison in its message and details.current_revision, a decimal string. That revision may change again: read the latest draft, review the intervening changes, and submit your intended edit against that revision rather than blindly retrying with a different revision.

Components

A component is one row on the public page: a name, an optional group heading, and a status — operational, degraded, partial outage, major outage, or maintenance. A page holds at most 100 components.

A component can optionally be associated with something you already track, so its status can be set from that context instead of by hand:

• Service — a response-catalog service. This is bookkeeping only; it does not drive the component's status automatically.
• Monitor — an external monitor. This is the only association that can drive the component's status automatically (see below).
• None — a plain component you set the status of by hand.

The association itself is never published — the public page never says which monitor or service a component is wired to, only its name and status.

Automatic updates

A component associated with a monitor can opt in to automatic updates: its public status is then derived from that monitor's health instead of being set by hand.

• A failing monitor sets the component to major outage.
• A healthy monitor sets it to operational.
• An active maintenance window covering the monitor sets it to maintenance.
• An unknown health, or a paused or deleted monitor, changes nothing — an uncertain reading is never shown as either healthy or down.

Only the derived status ever crosses this boundary. No check detail, response body, error message or other evidence from the monitor is ever part of a component's public status. Automatic updates are opt-in per component and reversible at any time; turning them off returns the component to whatever status you set by hand.

A component's status only changes on the public page once the page is published; an automatic update publishes an actual status change on its own, but only ever republishes the last thing you published — it never carries an unreviewed draft edit onto the public page.

Public incidents

A public incident is a statement to your users: a title, an impact (none, minor, major or critical), a status (investigating, identified, monitoring or resolved), and which components it affects. Opening one requires its first public update — the text your users read. A page holds at most 25 open (unresolved, or resolved within the last 7 days) incidents, each with at most 50 public updates; an incident resolved longer than 7 days ago quietly drops off the public page on its own, without you having to delete anything.

Post a new update to change the incident's status and add another line to its public timeline; setting the status to resolved resolves it (and records when), and moving it off resolved reopens it (and clears that time). You can optionally link a public incident to an internal one you are already tracking — that link, like every other internal reference here, is never published.

Maintenance

A maintenance announcement has a title, optional text, the components it affects, and a start and end time (the end must be strictly after the start). A page holds at most 20 of them; one whose window has already ended quietly drops off the public page. While a maintenance window is active, a component that opted in to automatic monitor-driven status shows maintenance instead of whatever its monitor reports.

Preview, publish and unpublish

Preview shows you exactly the document a publish would write right now — the same JSON your public page would serve — without publishing anything. Use it to check your draft before committing to it.

Publish snapshots the current draft and queues it for your public page. A publication moves through a small set of states:

• pending — queued; not public yet.
• published — live on the public page.
• failed — permanently refused (for example, the document was too large); the public page keeps showing whatever it showed before.
• superseded — a newer publication reached the public page first.

Publishing the same draft twice without changing anything in between returns the publication you already have rather than creating a new one. A pending publication is never shown as live; watch for it to move to published before assuming your change is visible to your users.

Unpublish takes the page off the public internet; a later publish makes the current draft public again under a new revision. Deleting a page removes it from your workspace; if it was public, its removal is queued the same way an explicit unpublish is. Deleting a project or an organization deletes every status page it holds in the same way: public pages are taken down, custom domains are released and every email subscriber's address is erased. A removal can take up to 60 seconds to reach the public page.

The public page

Anyone with the link can view your status page and its machine-readable form (your-page-address/status.json) — neither requires an account. The page shows each component's group and status, open incidents with their update timeline, and scheduled or in-progress maintenance.

If any component on the page is automatically updated, the page also carries a stale notice: a banner shown when the automatically derived statuses have not been confirmed fresh recently. A page with no automatically updated component never shows this notice — everything on it was set by a person, and stands until you change it.

Custom domain

By default your page is served at its Anectico address. You can instead serve it on a subdomain you already control — for example status.example.com — so it reads as part of your own site.

Only a subdomain works: an apex domain (example.com itself), a wildcard, or an IP address cannot be claimed. Point the subdomain at the platform with two DNS records, both returned by the claim (claim_status_domain, or anectico status-pages domain claim) and by a later read (anectico status-pages domain get):

• a CNAME record at your subdomain pointing at the target the platform gives you; and
• a TXT record proving you control the subdomain (shown once the platform has issued it — this can take a minute after claiming).

A DNS provider that "flattens" or proxies CNAME records at the apex is not supported for this subdomain — the record must resolve as an ordinary CNAME.

Your domain moves through a small set of states while it becomes ready:

• Pending ownership — waiting for the CNAME (and TXT, once issued) to be added and to propagate.
• Pending certificate — DNS is correct; waiting for the certificate to be issued, or the DNS stopped resolving to the target after having been active.
• Active — serving your page: the hostname and its certificate are both ready and the CNAME points at the platform.
• Failed — the platform could not activate the hostname; read the last_error and re-claim if needed.

Checks run automatically, roughly every 5 seconds while pending and hourly once active; An immediate re-check (verify_status_domain, or anectico status-pages domain verify) does not wait for the next pass. Removing the domain (remove_status_domain) stops serving the page on the custom domain and releases the hostname — your page keeps working at its regular Anectico address throughout, and removal can take up to about 60 seconds to take effect everywhere the page is cached.

Email subscribers

Visitors can subscribe to email updates from your public page — no account required. Subscribing is double opt-in: after entering an address, the visitor gets a confirmation email with a link that must be clicked within 24 hours, or the request expires and they can request another. Every update email carries an unsubscribe link, and unsubscribing always works even if requested twice.

A subscriber can choose to follow specific components instead of the whole page; leaving the choice blank follows everything. Only real changes trigger an email — a new public incident, a new update posted to one, or a new or changed maintenance window that concerns a subscribed component. A component's status changing on its own, with nothing else changing, never emails anyone. Reordering a maintenance window's selected components also sends no email when its title, body, start and end times, and component membership stay the same.

You see your subscribers as a masked address (for example p***@example.com), never the full address, along with their state (pending, confirmed or unsubscribed) and counts by state. You can remove a subscriber, which erases their address and stops any queued email to them.

The list also reports uncertain and failed sends. A send is uncertain when the platform could not confirm whether the email provider actually received it — it is never retried, since retrying could double-send. A failed send was refused by the provider or ran out of retries. Neither is an error you need to act on; they are shown so a repeated pattern is visible.

Permissions

status:read lists status pages, their drafts, publication history and the preview of the public document — this also covers reading the custom domain and the subscriber list. status:write edits drafts — components, public incidents, maintenance — claims, re-checks and removes a custom domain, and removes a subscriber; none of it makes anything public. status:publish publishes a draft, unpublishes a page and (with status:write) deletes one. Associating a component with a monitor also needs monitoring:read; associating it with a service, or linking a public incident to an internal one, also needs incidents:read. See Permissions reference.

Limits

• Public document: 256 KiB.
• Components: 100 per page.
• Open (unresolved or recently resolved) public incidents: 25 per page, 50 updates each.
• Maintenance: 20 per page.
• Slugs are permanent: once taken, a slug can never be reused for a different page, even after the page holding it is deleted.
• Subscribing: 5 requests per minute per address, and at most 60 emails sent per page per minute.
• A confirmation link is valid for 24 hours.