# InBrief Status documentation --- Every page from https://inbrief.sh/docs, in navigation order. --- # Quick start Source: https://inbrief.sh/docs/product/quick-start Create the page, add a service and confirm what customers can see. 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](https://inbrief.sh/docs/product/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](https://inbrief.sh/docs/product/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](https://inbrief.sh/docs/product/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](https://inbrief.sh/docs/product/branding): your logo, colour and typeface, so it reads as yours rather than as ours. - [Slack](https://inbrief.sh/docs/product/slack): so your own team hears about a failure before your customers do. - [Custom domain](https://inbrief.sh/docs/product/custom-domain): so it lives at `status.yourbrand.com`. - [Incidents](https://inbrief.sh/docs/product/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](https://inbrief.sh/docs/product/status-pages). ## 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](https://inbrief.sh/docs/product/billing). ## Next up --- # Monitors Source: https://inbrief.sh/docs/product/monitors Configure website, port, DNS and cron-job checks, group them, and understand when a service counts as down. A monitor is one thing we check on a schedule from outside your infrastructure. Each one appears on your public page as a service with its own current state and its own uptime history, and when it fails your team is told before your customers are. Dashboard → **Monitors**. The screen lists every monitor with its current state, its response-time trend and the allowance active for this account. ## Key features - Website, TCP, DNS, ping, mail-server and WebSocket checks. Cron-job heartbeat monitors remain in development preview and are disabled in production. - Checks every 1, 2, 3, 4 or 5 minutes, with the first check within a minute of saving. - Assertions on status code, body text and JSON fields, so a `200` with an error inside still counts as down. - Grouping and ordering for the public page. - Certificate-expiry warnings for encrypted targets. Domain-registration warnings require a separately enabled rollout. - Automatic incidents, opt-in per monitor, in every language you use. ## Adding a monitor Account owners and admins can read and change stored destinations, credentials, and request assertions. Operators can edit an existing monitor's name, group, check interval, and automatic incidents, or pause and resume it. Those edits preserve its request settings. Viewers have read-only access to safe details. Public status responses do not include monitor destinations. Dashboard → **Monitors** → **Add monitor**. This is the form you get. It is live: switch the kind and the fields change with it. ### What are we watching? | Kind | What it does | Use it for | | --- | --- | --- | | **Website** | Fetches an `https://` or `http://` URL and judges the response. | Sites, APIs, health endpoints. | | **A port** | Opens a TCP connection to a host and port. Nothing is sent or read; the check passes if the connection is accepted. | Databases, message brokers, SSH, mail submission. | | **A DNS record** | Resolves a name and, optionally, checks the answer. | Confirming a record still exists and still points where you think. | | **Ping** | Sends an ICMP echo and waits for the reply. | A router, a gateway, an appliance — anything with no service to connect to. | | **A mail server** | Greets the server and reads its reply. Nothing is sent and no mailbox is touched. | Mail that leaves your product: receipts, resets, alerts. | | **A WebSocket** | Opens a socket and checks the upgrade is accepted. | Live feeds, chat, dashboards — anything a page holds open. | | **A cron job** | Waits for your job to call a private URL. A missed check-in is the failure. | Backups, nightly imports, queue workers, anything scheduled. | ### Name Taken from the address unless you type one. This is what your status page calls the service, so write it the way a customer would say it. The name is set per language; the other languages are filled in for you and stay editable (see [Languages](https://inbrief.sh/docs/product/languages)). From the name in your default language we derive a **slug**: `Checkout API` becomes `checkout-api`. That is the stable identifier the badge, the widget, the feed's service filter and both APIs use. ### Check interval How often the address is checked, per monitor, so the endpoint that matters can be checked harder than the marketing site. The choices are 1, 2, 3, 4 or 5 minutes. New monitors default to 5 minutes. The faster cadences come with Monitoring and automatic detection, and the selector marks the ones this account does not include rather than hiding them. ### Group Optional. Type a group name, or pick one you already use. Monitors in the same group appear on the public page under one heading that visitors can collapse, and the heading shows the worst state inside it, so a group with one service down reads as a group with a problem. Leave it empty and the service sits at the top level. ### Automatic incidents Off by default. Turn it on and an incident is published to your page when this monitor stays down for 15 minutes, and resolved again when it recovers. The details, and the reasons for the delay, are in [Incidents](https://inbrief.sh/docs/product/incidents#incidents-this-product-opens-for-you). ## Website monitors The URL may be `https://` or `http://`. Plain `http://` is there because a great many internal tools and staging hosts speak nothing else, and a check you cannot create is a check nobody has. It comes with one rule: a plain `http://` address cannot carry credentials, in the basic-auth fields or in a header. Over an unencrypted connection anyone between us and the target can read them, and nothing on your screen would say so. Beyond that, everything under **Request settings** is optional: | Setting | Default | Notes | | --- | --- | --- | | Method | `GET` | `GET`, `HEAD`, `POST`, `PUT`, `PATCH` or `DELETE`. | | Expected status | `200`–`299` | Any range between 100 and 599. Widen it if a healthy endpoint answers `301` or `401`. | | Query parameters | none | One per line, as `name: value`. Added to the URL's query string. | | Headers | none | One per line, as `Name: value`. Sent with every check. | | Request body | none | Sent exactly as written. Only valid with a method that can carry one. | | Basic auth | none | Username and password, if the endpoint needs them. | ### Monitor is successful if A status code alone will not catch an endpoint that returns `200` with an error inside it. Four optional assertions run against the body once the status check has passed; a response that passes the status check but fails one of these counts as down. | Assertion | Passes when | | --- | --- | | Body contains | The response body contains that text. | | Body does not contain | It does not. Useful for a page that renders an error banner while still returning 200. | | JSON field | The field exists. Written as `$.status` or `$.checks[0].ok`; names and array indexes only. | | Expected JSON value | That field equals this value. Needs a JSON field to check. | ### Certificates Every encrypted target has its certificate watched, and your team is warned ahead of its expiry. The monitor's row shows how long the certificate has left. That means an `https://` website, a `wss://` socket, a port you tick **Connect with TLS** on, and a mail server on implicit TLS. A plain `http://` or `ws://` address has no certificate, and neither does a STARTTLS mail server from the outside; those rows say so rather than showing a check that never completes. ## Port monitors A host and a port. Tick **Connect with TLS** if the port expects a TLS handshake, as managed Redis or Postgres usually do. The check passes when the connection is accepted; nothing is written and nothing is read, so it cannot tell you the service behind the port is healthy, only that something is listening. Port 25 cannot be reached from here at all. For mail servers, monitor the submission or IMAP port (587, 993) instead. ## DNS monitors Enter the bare name to resolve, `example.com`, no scheme and no path, and a record type: `A`, `AAAA`, `CNAME`, `MX`, `NS`, `TXT`, `SRV`, `CAA`, `SOA` or `PTR`. Leave **expected value** empty and the check passes on any answer at all: the name resolves. Fill it in and the answer set must contain it, which is what catches a record that still resolves but now points somewhere wrong. Round-robin records are fine. A few types answer a different question. `SRV` watches which server handles a service, and compares the target host rather than its weight. `CAA` watches which authorities may issue certificates for the name, written as `issue=letsencrypt.org`. `SOA` watches the primary name server, which is what changes when a zone moves. `PTR` is the one that runs backwards: give it an IP address rather than a name, and it checks what that address says it is. **Resolver** is optional. Leave it empty and we ask our own resolver, which is what you want when you are watching your own zone. Put a public resolver's address there — `1.1.1.1`, `8.8.8.8` — and the check asks that one instead, which is how you see what your users' resolver sees while a change propagates. ## Ping monitors A host and nothing else. We send one ICMP echo and wait for the reply, which is the only check available for something that runs no service to connect to — a router, a gateway, a printer, an appliance. Two things to know. A great many hosts drop ICMP on purpose, so a ping monitor on a host that never answers is measuring a firewall rule, not an outage. And a ping tells you a machine is reachable, not that anything on it works; where there is a port to open or a URL to fetch, those say more. ## Mail server monitors A host, a port, and how the connection is encrypted. The check connects, waits for the server's greeting, says `EHLO` and reads the reply. That is the whole conversation: nothing is sent, nothing is delivered, no mailbox is touched, and we never sign in. | Encryption | Usual port | What happens | | --- | --- | --- | | STARTTLS | 587 | Connects in the clear, then upgrades after the greeting. | | Implicit TLS | 465 | Encrypted from the first byte. | | None | — | Stays unencrypted. For an internal relay. | Pick the port and the encryption follows it, which is nearly always right. Port 25 cannot be reached from here; use 587 or 465. Mail is the failure people find out about last, because nothing on the website changes when it stops. This check is what tells you before your customers do. ## WebSocket monitors A `wss://` or `ws://` address. The check opens the socket and passes once the server accepts the upgrade; it then closes without sending a message. A WebSocket usually fails in a way an HTTP check on the same host cannot see: the page loads, the API answers, and only the live feed is gone. This is the check that notices. ## Cron job monitors Cron job monitors are built and held behind a deployment switch while the receiver is proved out. They are not yet available on the hosted service, and the console offers the type only on a deployment with the switch on. What follows describes how they work where they are on. A cron job monitor waits for your job to check in. Saving one gives you a private URL; add one request to the end of your job, and the monitor records every run. | Setting | Default | What it means | | --- | --- | --- | | Expected every | 5 minutes | How often the job is supposed to run. | | Grace period | 60 seconds | How late a run may be before the monitor counts as down. | | Track runtime | off | Have the job call a `/start` URL first, and a run that takes longer than its limit is reported too. | The URL is shown once, when you create the monitor, and can be rotated later from the monitor. Your job can also call a `/fail` URL to report a run that ended badly, which marks the service down without waiting for the deadline. A cron job monitor stays off the public page until it has received its first ping, so a job you are still wiring up never shows as a failure. Cron job monitors have no response time: they report that a job ran, not how long a request to them took. They need the Heartbeat monitors capability. ## When a monitor counts as down **Two consecutive failed checks.** A single failure never changes what your public page shows; it is recorded, but the monitor keeps its previous state until a second check agrees. One dropped packet should not publish an outage. The moment the state does flip, your own team is told (see [Slack](https://inbrief.sh/docs/product/slack)). Whether anything appears on your _public_ page is a separate decision, covered in [Incidents & maintenance](https://inbrief.sh/docs/product/incidents). Recovery is immediate: one successful check and the monitor is up again. There is no manual override. A service is up or down because a check said so, and an incident is the place to explain anything the check cannot see. ## Response time Every website, port and DNS monitor also records how long each check took. Your public page shows the average beside the service, and expands into a day-by-day trend across the same history window the uptime bar covers ([Branding](https://inbrief.sh/docs/product/branding)); the same trend is on the monitor's row in the dashboard. | Question | Answer | | --- | --- | | What is averaged? | Completed checks only. Checks inside a [scheduled maintenance](https://inbrief.sh/docs/product/incidents) window are left out, exactly as they are left out of uptime; work you announced should not show up as your service getting slower. | | How is the headline figure calculated? | Across the whole window, weighted by how many checks each day actually ran. A quiet day cannot pull the average as hard as a full one. | | What about a day with nothing? | It is left out of the chart rather than drawn as `0 ms`. A service with no measurements at all in the window shows no chart, and no figure. | ## Order on the public page Services appear in the order you arrange them. Drag a monitor by its handle, or use the up and down buttons on its row, and the public page follows. Within a group the same controls order the group's members. Put the service customers care most about first. ## Domain registration Domain-registration warnings are still being built. Delivery is paused by default and requires a separately enabled rollout; adding a monitor does not enable these warnings. When enabled for your page, the feature checks registration expiry and can notify owners and admins by email, Slack and a `domain.expiring` webhook at 14 days, 3 days and on the expiry date. The monitor shows its registration-check state and any known expiry date. Keep your registrar's renewal reminders enabled. ## Pausing and deleting **Pause** stops checks and removes the monitor from your public page, keeping its history. Use it for a service you are decommissioning, or one you know will be noisy for a while. If the monitor was down and had opened an incident automatically, pausing it closes that incident rather than leaving it stranded open. **Delete** removes the monitor and its history permanently, and frees one monitor slot for the account. ## Allowlisting our checks If your service sits behind a firewall, a WAF or bot protection, make sure your checks can reach the endpoint. InBrief checks include a User-Agent that names InBrief. Use it to find check requests in your logs, but do not treat it as proof of identity: any caller can send the same header. Keep authentication and access controls in place. If you need an exception, scope it to the monitored endpoint and use a credential your service verifies. Do not bypass authentication or WAF protections based only on the User-Agent. Check addresses can change; no fixed source-IP range is promised here. ## Next up --- # Incidents & maintenance Source: https://inbrief.sh/docs/product/incidents Publish, update and resolve incidents, schedule maintenance and write postmortems. Monitors say whether something answers. An incident is what you write about it: the entry your customers read, subscribers are told about, and a procurement team scrolls through a year later. Dashboard → **Incidents**. The list shows what is live and what is posted, with a filter for each state, and the two buttons that start everything: **Post incident** and **Schedule maintenance**. ## Key features - Write in one language; the others are filled in for you and stay editable. - Updates with a status (Investigating, Identified, Monitoring, Resolved) that build a timeline. - Templates for the incidents you post more than once. - Scheduled maintenance with reminders; it starts, completes and overruns on its own. - Postmortems in Markdown, published under the incident. - Automatic incidents from monitors that stay down, behind two gates. ## Posting an incident **Post incident** opens a dialog with three tabs. These are its fields: ### What happened A **title** and a **summary**, in your default language. Keep the summary about impact rather than cause. “Checkout is returning errors for some customers” is what somebody needs at that moment; the database failover that caused it belongs in a later update. ### Scope & timing The **type** (an incident, or maintenance), the **services** it affects, and when it **started**. Attaching services is what marks them as impacted on your page and lets people filter the feed by them. A resolved time appears when you are posting something that is already over. ### Translations If your page publishes in more than one language, the translation is written for you when you publish. You can open this tab afterwards to read it and change any phrase; your edit is kept. See [Languages](https://inbrief.sh/docs/product/languages). ### Starting from a template At the top of the dialog you can pick a template. Applying one fills the fields; it publishes nothing, and you still review every field before you submit. Templates live in Dashboard → Incidents → **Templates**: five ready-made ones, and up to fifty of your own, each with a title, summary and default services, per language. ## Updates and statuses An incident is a thread, not a single note. Each update you post carries a status, is timestamped, appears under the incident on your page, and goes out to subscribers. | Status | Say it when | | --- | --- | | **Investigating** | You know something is wrong and not yet what. | | **Identified** | You know the cause and are working on it. | | **Monitoring** | A fix is in place and you are watching it hold. | | **Resolved** | It is over. This closes the incident. | Updates are append-only: a published update is part of the record and cannot be edited or removed. The rhythm that works is an update when something changes and an update when nothing has changed for a while; silence during an outage reads as nobody being on it. ### Publishing silently Every update has a checkbox: **Publish silently, no subscriber email or webhook**. Use it for a correction, a translation fix, or the fourth update in ten minutes. The timeline marks each update as _Published silently_ or _Notifications requested_, so you can always see which ones went out. ## Editing The pencil on an incident opens the same three tabs, for the title, summary, services and times. Editing does not notify anyone unless you tick **Email subscribers** in that dialog. ## Resolving Posting a **Resolved** update sets the end time, returns the affected services to normal on your page, and sends a final notification. Resolved incidents stay in the ledger permanently; that history is most of what makes a status page worth having. ## Postmortems A resolved incident gets a **Write postmortem** button. The postmortem is Markdown, written per language, with **Save draft** and **Publish**. Nothing is visible until you publish; the first publication tells subscribers, and later edits do not. Published postmortems appear under the incident on your page at their own address. ## Scheduled maintenance **Schedule maintenance** opens its own dialog: an announcement, the services and timing, and translations. | Field | What it does | | --- | --- | | Start | When the window opens. It appears on your page as planned work from the moment you publish. | | Planned end | When you expect to be done. | | Subscriber reminder | Off, or 1 hour, 6 hours, 24 hours, 48 hours or 7 days before the start. Subscribers are told when you publish and again at the reminder. | A window moves through its states on its own: _scheduled_, then _in progress_ when it starts, then _completed_ when the planned end arrives if the affected services are healthy. If they are not, it becomes _overrun_ and stays open until you finish it, so a window never quietly closes on a service that is still down. **Complete now** ends it early; **Cancel maintenance** withdraws it. Checks during the window are left out of uptime and response-time figures. If you also want visitors to your actual site to see a branded page during the window rather than a browser error, see [Outage page](https://inbrief.sh/docs/product/outage-page). ## Incidents this product opens for you When a monitor stays down, an incident can be opened on your page automatically, with a title and body in every language you publish. It is off by default and switched on per monitor. Two deliberate gates sit in front of it: - **Two consecutive failed checks** before the monitor is considered down at all. This is the bar for alerting your own team. - **Fifteen continuous minutes down** before anything is published to your customers. A blip that clears on the third check is not worth a permanent entry in your ledger, mailed to every subscriber, in every language. When the service recovers, that incident is resolved automatically too. Edit it and it becomes yours: we stop touching it. Nothing is opened during a maintenance window, or on top of an incident you have already written. One more guard, worth knowing about because it looks like a bug otherwise: if a large share of all monitors being checked fail in the same moment, that is treated as evidence the check path itself broke rather than the whole internet. Your team is still alerted; publishing to public pages is withheld. ## Doing this from your own systems The public API lets a deploy pipeline or an internal alert create an incident, edit it, append timeline updates and resolve it. The account needs the Write API capability. See the [Incident API reference](https://inbrief.sh/docs/developers/incident-api) for the supported fields. Use the dashboard for templates, postmortem publication, and maintenance settings such as planned end times and reminders. Those workflows are not exposed by the public Incident API. ## Next up --- # Internal page Source: https://inbrief.sh/docs/product/internal Reported traffic, failing services and endpoints that have no monitor. The Internal page shows request traffic reported by your own servers, alongside the status of the services your public page monitors. Use it to find failing endpoints and services that have stopped reporting. Open Dashboard → **Internal**; the account needs Internal analytics. This page is private to your team. Reported traffic does not publish an incident automatically. [Database Health](https://inbrief.sh/docs/product/database-health) is a separate optional feature for native database checks and application pool reporting. It does not replace the error heatmap. ## Getting data into it Send batches through the [Event API](https://inbrief.sh/docs/developers/event-api) using an ingest-scoped key. Its reference covers authentication, fields, batching limits and error responses. The v2 interface adds a stable reporter identity and heartbeat reports, so an idle service can still show that it is reporting. Send route templates such as `/v1/orders/:id`. A raw path such as `/v1/orders/8837` creates a separate endpoint for each order and can exhaust your endpoint allowance. ## What it shows The briefing compares reported traffic with your public status. The fleet map and service table show the same selection. Search or filter by service, region, team, response status, method or route prefix, then select a service to inspect its endpoints. The table shows requests, errors, error rate, average latency and p95 where measurements support it. You can change its ordering and inspect healthy services as well as failures. Choose the last hour (the default), 6 hours or 24 hours. Select a time range to narrow the investigation, or pin the view and copy a link for a teammate. A pinned view stops polling. InBrief event storage retains 14 days of traffic. ## Where your events are stored By default they live in our database: 14 days at one-minute resolution, included, nothing to configure. To store event history in your own warehouse, open Dashboard → **Settings → Storage**. This needs External event storage. Supported adapters are **BigQuery**, **ClickHouse** (Cloud or self-hosted) and **Snowflake**. Postgres, MySQL and Redshift are not supported destinations. | Primary event store | Traffic written to | Traffic read from | History retention | | --- | --- | --- | --- | | Our storage (default) | our database | our database | 14 days, fixed | | Your warehouse | your warehouse | your warehouse | whatever you set | The selected store owns event history. InBrief also retains reporter identity, region, team and reporting timestamps locally to track ingestion, plus encrypted connection credentials. Reporter metadata has no automatic expiry. Failed warehouse writes are buffered locally as aggregated batches under the limits below; this buffer is not a second complete event history. ### What changes when you switch You create the table. The settings page shows the exact DDL to run, and we never create tables in your account; the credential you hand us should reach that one table and nothing else in the project. History does not move with you. What is already in our storage stays there for the rest of its 14 days, and your warehouse starts from the moment you switch. The page also drops to polling every 60 seconds instead of 15, because each poll is now queries billed to your account. If the warehouse stops answering, the page reports that it is unavailable. An accepted batch waiting for delivery returns `202` with a `warning`. Buffering is bounded: at most 2,000 batches per status page, with older batches removed above that cap. Delivery stops after 50 failed attempts; exhausted batches become eligible for deletion seven days after their creation. Events can be lost if these limits are reached. Switching back to InBrief storage discards pending external batches. Restore the warehouse connection before switching, and check that recent traffic arrives. Keep your own source records if you need to recover gaps; automatic replay stops at the retry limit. Retries can also produce duplicates after a timeout. A deduplication key accompanies each batch, but provider deduplication is bounded. Duplicates can inflate request and error counts. Full detail, including the retention and cardinality limits, is in the [Event API reference](https://inbrief.sh/docs/developers/event-api). ## Reading service states A reporter with errors in the selected window is **failing**, regardless of its error rate. Without errors it is **late** after the greater of two minutes or three expected reporting intervals, and **silent** after ten minutes. Otherwise it is **clean**. These states describe reported traffic, not the public page's uptime verdict. Without a v2 heartbeat, reporting health is **estimated** from traffic. No requests can mean an idle service, so missing traffic alone does not prove it is offline. Fewer than 100 requests in the window is marked **thin**; read its error rate with that sample size in mind. ## Comparing traffic with public status | Signal | What it means | | --- | --- | | **The gap** | Your status page is green and your traffic says otherwise. The page names the service responsible and offers to open an incident. | | **No monitor** | A failing endpoint with nothing watching it. Tagged in place, so you can see which failures your public page knows nothing about, and which are worth adding a [monitor](https://inbrief.sh/docs/product/monitors) for. | | **Stopped reporting** | A service that was reporting and went quiet. Called out separately, with an estimated reporting state when no heartbeat is available. | ## From here to your public page With incident-publishing access, select a service and publish an incident after reviewing its text and affected services. Translation and subscriber delivery use the capabilities enabled on your account. Alert rules are configured separately from public incident publishing. See [Incidents & maintenance](https://inbrief.sh/docs/product/incidents). ## Next up --- # Database Health Source: https://inbrief.sh/docs/product/database-health Private database connections and application pool diagnostics. **Release pending.** This guide describes the Database Health release being verified. Availability in your deployment is not yet confirmed. Database Health has two setup options: connect to MongoDB, PostgreSQL or MySQL with a dedicated monitoring user, or send measurements from your own network through REST or the optional Node.js reporter. Both feed a private dashboard under **Internal → Database Health**. The existing error heatmap remains a separate Internal page. ## Choose how to connect | Option | Use it for | What you need | | --- | --- | --- | | Connect in the dashboard | Reachability, probe latency and supported server connection counters | A reachable database endpoint, verified TLS and a dedicated monitoring login | | REST server observations | Databases reachable only inside your network | Your own collector and a page-scoped ingest key | | Application reporter | Pool demand, idle connections, waiting and supported acquisition measurements | Instrument the application pool using a supported adapter, or implement the versioned REST pool contract | The direct connection uses the database protocol. It does not use the MongoDB Atlas Administration API. Support follows the database engine and permissions; it is not a claim that every managed provider or engine version has been verified. Other engines need a supported adapter before they can be selected. ## Connect from the dashboard 1. Select **Connect a database** and choose MongoDB, PostgreSQL or MySQL. 2. Enter the hostname, database and dedicated monitoring credentials. MongoDB SRV discovery is available for mongodb+srv hosts. A custom certificate authority can be supplied; certificate and hostname verification remain required. 3. Choose a check interval from one to five minutes. New connections default to one minute; existing connections retain five minutes unless changed. 4. Select **Test connection**, review any unavailable diagnostics, then save. A successful connection test does not guarantee every diagnostic is permitted. 5. Check the saved row for its last check, next due time and measurements. Change the interval without entering credentials again. Use **Manage connection** to pause, resume, replace credentials or disconnect. Public-network destination checks reject private and loopback addresses. Use outbound REST reporting when the database is private. Saving a connection does not change database settings or application pools. ## What the direct checks measure | Engine | Measurements | Monitoring access | | --- | --- | --- | | MongoDB | Ping latency, current connections and a connection limit when reported | serverStatus privilege on the cluster resource; clusterMonitor includes it and broader monitoring privileges | | PostgreSQL | Probe latency, client connections, max_connections, active sessions and lock waits | CONNECT to the database; pg_read_all_stats for cross-session activity and lock-wait counts | | MySQL | Probe latency, Threads_connected, Threads_running and max_connections | A login allowed to connect to the selected database; the fixed SHOW commands do not require administrative privileges | Unknown or restricted measurements stay unknown. A server connection total includes other clients and monitoring connections. These checks do not collect host CPU, memory, disks, query text, documents or replication diagnostics. ## Check timing and history Workers scan for due checks every ten seconds. A due time is a scheduling target, not a promise of execution at that exact second. Small jitter spreads load; temporary failures back off up to 30 minutes. Authentication, TLS, network-policy or unreadable-credential failures stop automatic checks until corrected or retried. Each page supports up to 20 saved connections. Each connection retains at most 288 samples for up to 24 hours. At a one-minute interval the sample cap holds about 4.8 hours, so it does not guarantee a full day of history. The selected interval affects direct checks, not SDK reporting frequency. ## Should I reduce the pool? Server connection counts alone cannot answer this. Application evidence must show peak busy connections, waiting, failures, configured limits and enough continuous coverage. The dashboard may suggest a smaller pool for a controlled trial when that evidence supports it. It does not change pool settings or certify a production-safe size. For multiple Cloud Run API and worker instances, include every relevant application pool and deployment revision. Validate a proposed change during representative traffic and overlapping deployments. PostgreSQL and MySQL adapters currently leave some required sizing evidence unknown, so the dashboard may correctly return insufficient data. ## Price and access Database Health is a separate optional feature at **$3 per paid status page per month**, charged linearly: two paid pages cost $6 per month for this feature before applicable discounts or tax. The account capability is `database.health`. Internal analytics remains a separate $7-per-account monthly feature for the error heatmap. Buying one does not imply the other. Continue with the [Database Health reporting reference](https://inbrief.sh/docs/developers/database-health) for authentication, limits and SDK support. --- # Status page analytics Source: https://inbrief.sh/docs/product/analytics See page loads, visitor-days and subscription conversion for each public page. A status page is read most on the days you would rather it were not. Analytics tells you how many people came, how many of them were new that day, and how many decided to subscribe, so you can judge whether the page is doing its job during an incident and whether the subscribe box is earning its place. Dashboard → **Analytics**. It needs the Status page analytics capability, and it is scoped to the status page you have open; an account with several pages has an analytics screen for each. ## The screen | Card | What it counts | | --- | --- | | **Page loads** | Every time the public page was opened in the window. | | **Visitor-days** | Distinct visitors per day, summed across the window. One person who comes back on five days counts five. | | **Confirmed subscriptions** | People who subscribed and clicked the confirmation email. | | **Conversion rate** | Confirmed subscriptions divided by page loads. | The chart and the table beneath it break the same numbers down by day. The window is 7, 30 or 90 days, chosen at the top right. ## What is measured, and how The counts are aggregates. To tell a returning visitor from a new one within a day, the page sets a small cookie that holds only the date of the visit; it identifies nobody, carries no id, and is not readable by script. There is no fingerprinting and no third party. Daily rows are kept for 90 days and then dropped, which is also why the widest window is 90 days. Because the numbers are aggregates, there is nothing here about an individual: no addresses, no paths, no list of who came. ## Reading it during an incident A spike in page loads with flat subscriptions usually means people found the page but got what they needed without signing up, which is fine. A spike in both is the moment to check that the confirmation email is arriving quickly ([Subscribers](https://inbrief.sh/docs/product/subscribers)). A spike in nothing during a known outage can mean customers do not know the page exists. Link to it from your site, add a [badge](https://inbrief.sh/docs/product/badges-and-widgets), or use the [outage page](https://inbrief.sh/docs/product/outage-page). The website widget remains in development preview. ## Next up --- # Languages Source: https://inbrief.sh/docs/product/languages Choose published languages and review the automatically prepared translations. Publish your status page in English, Arabic, French and Spanish, within your account's language allowance. You can write translations yourself. Automatic translation requires the multilingual feature to be included and active on your account. Dashboard → **Languages**. The screen lists every language with a checkbox to publish it, a link to view that version of the page, and a count of what is translated and what is still missing. It shows how many published languages this account allows and stops you choosing more. ## Your default language One language is the default. It matters in three places: it is the language you write incidents and monitor names in, the one everything else is translated _from_, and the one a visitor gets when their own language is not among yours. **Make default** beside any published language changes it. ## How translation works When AI translation is available, saving an incident, an update or a monitor name starts translation into the other languages. You are not asked to wait for it and you are not asked to approve it; during an outage, the worst possible time to add a step is while somebody is trying to publish. Every translation is editable. If a phrase matters, open the incident and fix it; your edit is kept and is not overwritten. When something is still missing, the Languages screen says so beside that language, and a **fill** action translates whatever is left, which is what you want right after adding a language to a page that already has history. ## Right-to-left Arabic renders the page right-to-left in full: layout, alignment and punctuation, not just the text, with Arabic-Indic numerals. Nothing to configure; publishing in Arabic is all it takes. ## What a visitor sees Each language has its own address, and the page opens in the visitor's own language when it is one you publish, and in your default language otherwise. They can switch languages themselves at any time, and the choice sticks. Everything else follows the same rule: subscriber emails go out in the language that subscriber chose, enabled badge and widget previews render in the language you picked for them, and the RSS feed takes a `?lang=` filter (see [Badges & feeds](https://inbrief.sh/docs/developers/badges-and-feeds)). ## Adding or removing one With AI translation available, adding a language translates your existing incidents into it. Turning one off hides it from visitors; the text is kept, so adding it back does not mean translating your history again. Your default language cannot be removed. Change the default first if that is what you mean to do. ## Next up --- # Branding Source: https://inbrief.sh/docs/product/branding Set the logo, accent, typography, theme and public history window. A status page is the one page customers open when they are already unhappy. It should look like it belongs to you. Dashboard → **Branding**. The editor on the left, your real page on the right. It needs the Branding and custom domain capability; without it the page uses InBrief's defaults and the screen says so. ## Name and logo Your organisation's name is set per language, so it can be written natively on each version of the page. The logo is a URL to an image you host; an SVG or a PNG with a transparent background works best, since it sits on both light and dark backgrounds. The logo is a mark beside the name, not a replacement for it. For link-preview cards, the logo must be reachable over public HTTPS. Private network addresses are refused, including redirect destinations. Images larger than 512 KiB or taking more than two seconds to load are omitted from the card; the rest of the preview still renders. ## Accent colour One colour, used for links, the subscribe button and highlights. The editor previews it in the three places it actually lands, as a button background, as text on light, as text on dark, and warns you when a colour that looks fine in a palette is unreadable as text on a dark page. Status colours are not configurable. Green for operational and red for down are not decoration; a visitor should not have to learn your palette to find out whether the service is up. ## Typeface | Preset | Reads as | | --- | --- | | Editorial serif | The default. Considered, calm. | | Modern sans | Neutral, matches most product UIs. | | Technical mono | Developer-facing, matches a docs site. | ## Light and dark By default the page follows each visitor's own device setting. You can force it to always light or always dark instead, worth doing when your logo only works on one of them. The preview has its own light and dark toggle so you can check both whatever the setting says. ## History window How far back the uptime bars on your page go: 7, 14, 30, 60 or 90 days. The dashboard offers the windows enabled for this account. Longer is not automatically better. A long window of history is a strong claim when it is largely green, and a permanent reminder when it is not. ## Preview The preview beside the editor is your real page, rendered by the same code visitors get, with the settings you are editing applied. Visitors never see it; nothing is live until you save. ## Beyond the page Branding has three companions in the sidebar, each with its own guide: - [Custom domain](https://inbrief.sh/docs/product/custom-domain): the address it is served on. - [Embed](https://inbrief.sh/docs/product/badges-and-widgets): badge and feed integrations, plus named badge and website-widget previews that use your page's identity. - [Outage page](https://inbrief.sh/docs/product/outage-page): which inherits your logo, colour and typeface. ## Next up --- # Custom domain Source: https://inbrief.sh/docs/product/custom-domain Point a DNS record at InBrief and check that the certificate was issued. Your page is always reachable at `status.example.com`. A custom domain adds your own address alongside it, and on the page customers are sent to during an outage, an address they recognise is worth having. Dashboard → **Branding → Custom domain**. This requires the Branding and custom domain capability, and an owner or admin. ## Setting it up 1. Enter the hostname you want, for example `status.yourbrand.com`. 2. Add the CNAME record shown on that screen at your DNS provider. 3. Choose **Refresh status**. Once the record resolves, the certificate is issued automatically. Issuing usually takes a few minutes. The screen shows where in that sequence you are, so a domain still waiting on DNS is distinguishable from one waiting on a certificate. ## Two things that catch people out - **Use a subdomain.** `status.yourbrand.com`, not `yourbrand.com`. Most DNS providers cannot put a CNAME on a bare domain at all. - **Do not proxy the record.** If your DNS provider offers a proxy or CDN toggle on individual records, this one must be set to DNS-only. A proxied record prevents the certificate from being issued. ## After it is live Both addresses keep working, and everything follows the new one automatically: badge click-throughs, the RSS feed, subscribe links and the links inside notification emails. The badge image itself stays on your permanent InBrief address, so a README never has to change when the domain does. Certificates renew on their own. There is nothing to install and nothing that expires on you. ## Removing it Removing the domain returns your page to `status.example.com`, which never stopped working. Remove the CNAME at your DNS provider afterwards. If the account lapses to no subscription, the custom domain stops serving and the InBrief subdomain takes over, so the page itself stays reachable. Deleting a status page puts its custom domain in a seven-day quarantine before anyone else can claim it. ## Next up --- # Outage page Source: https://inbrief.sh/docs/product/outage-page The separate page visitors see when your main site cannot answer. A status page only helps the customers who know it exists. Everyone else meets your site's own failure: a blank page, a proxy error, a browser message about not being able to connect. The outage page replaces that with a branded page of your own, served from outside your infrastructure, so it is still there when your infrastructure is not, and it can say what is actually happening. Dashboard → **Outage page**. This requires the Outage continuity capability. ## How it is wired up 1. **Generate snippet** and paste it into your CDN or edge, once. It carries no settings of its own, so you never paste it again; everything about how the page looks and what it says stays editable here afterwards. 2. The screen checks that the snippet answers, and says _Not set up yet_ until it does. The snippet **fails open**. If we are slow, unreachable, or answer with something unexpected, it falls through to whatever your edge would have done without it. Code you paste into your own production path should not be able to take your site down, least of all during the moments it exists to help with. ## What visitors read Your logo, accent colour and typeface come straight from [Branding](https://inbrief.sh/docs/product/branding), so it matches your status page without being configured twice. If an incident is open, its summary is shown; visitors get the real reason rather than a generic apology. Otherwise the **message** you write here is used, per language. Beneath it, a box lets a visitor leave their email to be told the moment it is fixed, and a link opens the full status page. You can add your own CSS, which loads after ours so your rules win without `!important`, and your own HTML above the headline. Scripts and event handlers are stripped: this page is served on your own domain, and a status vendor that can inject script there is a status vendor with a hole in it. The preview on the right renders the page in each of its three moods, outage, maintenance and incident, in each of your languages. A dark variant is served to visitors whose device is set to dark. ## Maintenance mode Maintenance mode shows the outage page to **every visitor of your site**, deliberately, even while your site is perfectly healthy. It is for planned work: take the site out of service behind a page that explains why, instead of leaving a half-migrated application answering requests. It always has an expiry, and it defaults to the end of your next scheduled maintenance window. There is no way to leave it on indefinitely; the failure mode of this feature is somebody enabling it at 23:00 and forgetting, and an expiry is the only reliable protection against that. You can turn it off at any time. ## Next up --- # Badges and widgets Source: https://inbrief.sh/docs/product/badges-and-widgets Put a live status badge in your README or a status widget on your own site. A badge puts current status in your README and links to your status page. The existing `/badge.svg` and `/badge.json` routes are documented in the [Developer badge reference](https://inbrief.sh/docs/developers/badges-and-feeds). Named badge and widget editors appear under Dashboard → **Branding → Embed** when your account has the relevant access. The editors below are previews: named modern embeds are not released for general Cloud use, and widget delivery is disabled in production. A demo or visible editor does not mean an installation can be served publicly. In an enabled development environment, the screen supports up to 20 active installations in total, each with a name, scope and copy menu. Check both account access and delivery availability before relying on an installation. ## Badges A badge is an SVG image, rendered fresh on every request with the live state of your page or of one service. In the preview environment, **Add badge** opens this editor: | Setting | Choices | | --- | --- | | Badge for | The whole page, or exactly one service. | | Language | Any language your page publishes. | | Style | **Signal** (state, uptime and freshness), **Compact** (state only) or **Uptime** (the percentage, large). | | Theme | System, light or dark. System follows the reader's device. | | Palette | InBrief, or high contrast for readers who need it. | | Attribution label | The small word beside the state, `inbrief` by default. | | Content and motion | Whether to show uptime, show how recently it was checked, and whether the live signal pulses. | The preview on the right is the badge itself, rendered on a light and on a dark background from your unsaved edits. Once the badge is saved it also shows the three ways to install it: **Markdown** for a README, **HTML** for a page, or the **direct URL** of the image. The image lives at a permanent address on your InBrief origin, and clicking it opens your page at its current branded address, so the snippet never has to change when your domain does. A badge can be edited after it is installed; the address stays the same and the image changes on the next load. Revoking a badge turns its address into an empty response, so a README you no longer control cannot keep showing a stale state. The older `/badge.svg` and `/badge.json` addresses documented for developers keep working alongside. ## The website widget The widget is a small panel on your own site that shows the current state and, when something is wrong, the open incident or maintenance. It runs in an isolated frame, so it cannot read or change anything on your page. In the preview environment, **Add widget** opens this editor: | Setting | What it does | | --- | --- | | Show widget | **Always**; only during **issues**; or during issues **and maintenance**. With the last two the widget is invisible while everything is fine, which is what most sites want. | | Follows | The whole page, or up to five services. | | Placement | A corner or edge of the viewport, a bar across the footer, inline where the script is, or inside an element of yours by id. | | Size | **Compact**, one line; or **expanded**, with the incident summary. | | Theme | System, light, dark, or **custom**: your own background and text colours, with the status colours derived to keep at least 4.5:1 contrast, or every colour set by hand. | | Advanced behaviour | Pulse, uptime, freshness, attribution and whether a visitor can dismiss it (it returns on the next page load). | The preview renders your unsaved edits with the real widget runtime, and lets you switch between an operational, degraded, outage and maintenance state to see what visitors would get in each. When the display mode would hide the widget in the state you picked, the preview says so instead of pretending. ### Installing it Once saved, the widget offers four formats: | Format | Use it when | | --- | --- | | **Script** | The normal choice. One `