Quick start

InBrief gives your customers one place to check whether your service is working, and gives your team one place to say so. This guide takes you from a fresh account to a public page with a monitored service on it. Everything you set up here can be changed later, except the page's address.

What you get

• A public status page with a current state for every service, uptime history and a subscribe box.
• Monitors that check your services from outside your infrastructure and tell your team first.
• Incidents and scheduled maintenance, written once and published in every language your page uses.
• Email and chat updates for subscribers. Browser notifications and WhatsApp remain in development preview.
• Badges, an outage page and a JSON API for your own surfaces. Named embeds and the website widget remain in development preview.

1. Choose your address

Signing in for the first time drops you into a short setup. The first question is the address of your page: status.example.com, lowercase letters, digits and hyphens.

This one cannot be changed later. It is the address that ends up in your customers' bookmarks, in the badge in your README and in the RSS feed people subscribe to, so it is deliberately fixed. Pick the name of the company or the product, not of a team or a quarter. If you plan to serve the page on your own domain as well, you still choose a slug now; both addresses keep working (see Custom domain).

2. Choose your languages

Pick the language the page is written in, and any others you want it published in. One of them is your default language: the one you write incidents in, and the one everything else is translated from. See Languages.

3. Add your first monitor

A monitor is one thing we check on a schedule. Give it a name your customers will recognise (“Checkout API”, not “prod-lb-03”) and the address to check. The first check runs within a minute of saving, so you do not have to wait out a full interval to find out whether you typed the URL correctly.

The setup asks for a website URL because that is what most people start with. The full form, with ports, DNS records, pings, mail servers, sockets and cron jobs, is in Monitors.

4. Open your page

That is a working status page. Dashboard → View opens it in a new tab so you can see exactly what a customer sees: current state per service, uptime history, and a Get updates button.

What is worth doing next, roughly in the order it pays off:

• Branding: your logo, colour and typeface, so it reads as yours rather than as ours.
• Slack: so your own team hears about a failure before your customers do.
• Custom domain: so it lives at status.yourbrand.com.
• Incidents: worth reading before you need it, not during.

Finding your way around the console

The sidebar is organised by job. Monitors and Incidents are the two you open during an outage. Analytics and Internal are the two you read afterwards. Languages, Branding and Outage page shape the public page. Notifications holds every channel, and Settings holds the account: team, audit log, API keys, storage, billing.

The page switcher at the top of the sidebar shows which status page you are working on. One account can run several; see Run more than one status page.

What this account can use

A new account starts on a 14-day trial of released Cloud features, with no card required. Features still being built or awaiting release are not included in trial access. When the trial ends you keep what you bought, and the console tells you plainly when a screen needs a capability the account does not have. Before relying on a monitor allowance, an API or a custom domain, confirm the active configuration under Settings → Billing. See Billing and capabilities.

Next up