sections
Get startedWhat is Tissue Mast?Watch your first siteWatch a cron job
MonitorsProbesVitalsRun signalsDeploys
Alerts and on callChannels and levelsOn callDeliveryMaintenance windows
Incidents and statusIncidentsStatus pagesUptime and reports
Mast PagerMast PagerOn iPhoneOn Android
IntegrationsSending alertsDestinationsRecipesHome AssistantChannels as codeThe APIMoving from Opsgenie
AccountPlans and limitsBilling
on this page

Incidents and statusStatus pages

Status pages

A status page is a public page that shows your users what your probes and vitals see, with room for you to write on it. Make one under Status pages in the web app. New status page asks for an address, a title, and the components to show.

  • The address is 3 to 40 lowercase letters, digits and dashes, and the page is served at tissue.systems/mast/status/<address>. Anyone with the URL can read it, with no sign-in.
  • Components are rows, each with a label and a source: one of your probes or one of your vitals. The row shows the source's state as the public sees it: up, slow or down for a probe, late or flatlined for a vital.
  • Incidents on the page can be posted automatically, from the moment a probe or vital goes down until it recovers, or only when you write them.

Writing updates

Updates are written by hand from the page's edit screen, each with a kind, Planned maintenance, Investigating, Identified or Resolved, and a line of text. They show on the public page newest first.

How many you get

Free has no status pages. Solo has 3, Team 5, Company 10. Deleting a page stops its address at once.

Each component also carries its uptime for the last full month. Uptime and reports has how it's counted.

A single vital also has a badge for a README, which needs no page and works on Free.

Your own domain

On Solo and up, a status page can also be served on a subdomain of your own, such as status.example.com. It has to be a subdomain: example.com itself can't hold the CNAME record the page needs. It also has to sit under a public suffix such as .com or .co.uk, so IP addresses and internal names like .local are refused, and so are names under tissue.systems, tissue.dev and any other domain our nameservers serve. International names go in their xn-- form, the way your DNS host shows them. A name is served by one status page at a time.

Set it as custom_domain on the page, and the reply lists the two records to publish at your DNS host:

PATCH /v1/mast/status-pages/sp_8f2c41d0
Authorization: Bearer tok_...

{ "custom_domain": "status.example.com" }
"domain": {
  "name": "status.example.com",
  "state": "pending",
  "records": [
    { "type": "TXT",   "name": "_mast-challenge.status.example.com", "value": "3f9c...e1" },
    { "type": "CNAME", "name": "status.example.com", "value": "edge.tissue.dev" }
  ],
  "serving": false,
  "checked_at": null,
  "verified_at": null,
  "error": null
}

The TXT record proves the name is yours, and the CNAME sends its traffic to us. Once both are published, ask for a check:

POST /v1/mast/status-pages/sp_8f2c41d0/domain/verify

The page comes back with domain.state set to one of these:

  • verified: both records were found. The page is live on https://status.example.com, with its own certificate, and / goes straight to it.
  • failed: one of the records is missing or doesn't match, and domain.error says which. Fix it and check again. DNS changes can take a while to reach everyone, so a check straight after publishing can fail and a later one pass.
  • pending: nothing was checked yet, or DNS couldn't be read at all. The check changed nothing; try again in a minute.

A check where DNS couldn't be read at all, such as a lookup that times out or a resolver answering SERVFAIL because the zone's DNSSEC is broken, never changes the state, whatever it was. The reply's check.transient is true when that happened.

domain.serving is true while the page is actually live on the name. A verified domain stops being served when the account's plan drops below Solo or the page is paused over its plan's status page limit. It stays verified, serving turns false and domain.error says which, and it's served again once that's sorted out, without a new check.

A domain that's verified stays verified when a check misses its records, so a check made halfway through a DNS change can't take the page down. That lasts a day from when the records were last found: after that, a check that still misses them moves the domain to failed, the same as our own re-check below. Changing custom_domain starts over with a new TXT value, and setting it to "" removes the domain. Checks are spaced at least 10 seconds apart per page; one sooner answers 429.

Setting a name another status page has already claimed isn't refused, since a claim proves nothing until it's checked. The page whose TXT value is in DNS is the one that verifies, and when it does it takes the name over: the page that held it goes to failed with a note saying so. A name that a Cell on Tissue has already verified answers 409. If that name is yours, write to support@tissue.systems.

We also check every verified domain again every six hours. If the records have been missing or wrong for a day, the domain goes to failed and within a few minutes the page stops being served there; a DNS outage that leaves the records unreadable doesn't count. Publish the records again and check to bring it back.

The page on your domain is the same page as at tissue.systems/mast/status/<address>, which keeps working too. Nothing else is served on your domain.

Coming soon

  • Email to subscribers.
  • Publishing the page as a Cell on your own account.