Publish a status page for your customers

When your service breaks, your customers find out before you have said anything, and your support inbox fills with the same question. A status page answers it in one place: what is affected, what you know, and when you will say more.

This post sets up a status page in ZipLogger, links its components to uptime monitors and heartbeats so their state stays current, and walks through posting an incident and a maintenance notice.

Create the page

Open Alerts → Detection → Status pages and click + New status page. Give it a Title, such as "Acme Cloud", and an Address. The page will live at:

https://app.ziplogger.ai/status/acme-cloud

The address is 3 to 64 lowercase letters, digits and dashes, unique across ZipLogger. A few, such as status, api and admin, are reserved.

A new page is a draft. Until you publish it, the address answers 404 to everyone, so you can set it up without anyone seeing a half-built page.

Add components

A component is a part of your service that a customer would recognise: "API", "Dashboard", "Webhooks", "EU region". On the Components tab, click + Add component for each one. A component has a name, an optional description and an optional group, so "API" and "Webhooks" can sit under "Platform".

Each component gets its state from one of three places:

• An uptime monitor. Choose the monitor from the list, where uptime monitors are grouped under Uptime monitors. When the monitor is up the component shows Operational, when it is down it shows Major outage, and when the monitor is paused or has not run yet it shows Unknown. If you have no monitors yet, the uptime monitoring post sets one up.
• A heartbeat. Heartbeats are grouped under Heartbeats in the same list. A heartbeat watches a scheduled job, such as a nightly import or a billing run. When its last run succeeded the component shows Operational, when a run was missed or failed it shows Major outage, and when the heartbeat is paused or has never been pinged it shows Unknown. The cron job monitoring post sets one up.
• By hand. Choose Set by hand and pick Operational, Degraded performance, Partial outage or Major outage. Use this for things a URL check cannot see, such as "Email delivery".

Click Save components. A page holds up to 50.

Settings and publishing

On the Settings tab:

• Support link: a URL or mailto: address, shown as "Report a problem".
• Description: one or two sentences at the top of the page.
• Show 90-day uptime bars under each component that has a monitor.
• Let visitors subscribe (email, Slack, webhook).
• Also by text message (SMS), off by default (see SMS subscribers below).
• Published.

Tick Published and save. The page refreshes every minute.

Who can see it

By default, anyone with the address can see a published page, without signing in. Under Who can see it you can limit that:

• Only people with the password. Set a password of at least 8 characters. Visitors enter it once, and their browser stays unlocked for 30 days. Changing the password signs out everyone who unlocked the page.
• IP allowlist. Addresses or CIDR ranges, such as 203.0.113.0/24 or 2001:db8::/32, one per line or comma-separated. Visitors from other networks see nothing, even with the password.

You can use both together. The limits apply to everything the page serves: the page itself, its incident history, its RSS feed, its badge and its subscribe box.

Post an incident

On the Incidents tab, click + Report an incident:

• Title: what customers will recognise, for example "Elevated error rates on checkout".
• Impact: Minor (degraded performance), Major (partial outage) or Critical (major outage). An open incident makes the components it names show at least that state, even when their monitors are up. An incident that names no components applies to all of them.
• Status: investigating, identified, monitoring or resolved.
• Message: what customers see, and what you are doing about it.
• Show on the page to publish it, and Notify subscribers to send it.

Click Post. As you learn more, post updates on the same incident. Each update can move the status, and the timeline only grows: an update is never edited away. When it is fixed, post a last update with the status resolved. Resolved incidents stay on the main page for 14 days. After that, visitors find them through Older incidents, which pages back through the full history.

The banner at the top of the page always shows the worst state of any component.

Automatic incidents

On its own, a failing monitor changes a component's state but writes nothing on the page. "Major outage" with no explanation is what makes people open support tickets, so you can let ZipLogger post a first notice for you.

Under Automatic incidents on the Settings tab, tick Open an incident when an uptime monitor or heartbeat behind a component goes down, and resolve it when it recovers. When a linked monitor goes down, the page gets one incident titled with the affected components followed by "unavailable", with Major impact. When the monitor recovers, ZipLogger posts a resolved update to it. A linked heartbeat works the same way: a missed or failed run opens the incident, and the next successful run resolves it. Tick Notify subscribers about automatic incidents too if subscribers should hear about them; otherwise they appear on the page only.

An automatic incident is a starting point. You can edit it and post updates to it like any other, and that is where you explain what happened.

If you switch off or delete an uptime monitor, or pause or delete a heartbeat, while its automatic incident is open, ZipLogger resolves that incident, because no later check would. Incidents a person posted are never touched.

Schedule maintenance

Click + Schedule maintenance, give it a title, a message, the affected components, and Starts and Ends (at most 14 days apart). Visitors see it under Scheduled maintenance before it begins. Between the start and the end, until you mark it completed, the components it names show Under maintenance.

During that window, failed checks of those components' monitors count as maintenance in the uptime bars, not as downtime. That is the point of announcing it.

A status page notice does not stop paging, though. To keep your own on-call from being woken by the planned work, also add a maintenance window under Alerts → Delivery → Maintenance windows.

How the uptime bars are calculated

Each bar is one day of the linked monitor's checks: up checks divided by up plus down checks. A day with no checks is grey and says "no data", never 100%. A day whose only failures happened during announced maintenance shows as maintenance. The figure under the bars is uptime over the 90 days.

Subscribers, RSS and the badge

With subscriptions on, the page has a Get updates box with three choices, and a fourth, SMS, when you switch it on:

Every channel is double opt-in. The subscriber first gets a message with a confirmation link, and nothing else is sent until someone clicks it, so nobody can subscribe someone else. The page gives the same answer whether or not the address was already subscribed, so it cannot be used to find out who your customers are.

On a page with more than one component, a visitor can untick All components and choose the ones they care about. They then hear only about incidents that name one of those components, or that name none, which means all of them.

Webhook updates are signed. The confirmation message carries a signing secret, and every request has an X-ZipLogger-Signature header of the form sha256=<hex>: the HMAC-SHA256 of the raw request body with that secret. Check it before you trust the body.

Subscribers get updates for incidents or updates posted with Notify subscribers ticked. You see and remove subscribers on the Subscribers tab, which shows only the host of Slack and webhook addresses because the full URLs are secrets. The list is never public. A page can have up to 5,000 subscribers.

SMS subscribers

Texts cost money, so SMS is off by default on every page. Tick Also by text message (SMS) on the Settings tab (it sits under Let visitors subscribe, which must be on) and the Get updates box offers SMS. The visitor enters a number in international format.

Every text is paid by your workspace: from its SMS allowance and credits on ZipLogger's sender, or through your own Twilio or Telnyx account if you connected one under Settings → Integrations. Your plan must include phone notifications, the same as SMS paging.

SMS is double opt-in like the other channels. The first text is only a confirmation link, and nothing else is sent until someone opens it:

Acme Cloud status: confirm text updates at https://app.ziplogger.ai/status/acme-cloud?confirm=… . Reply STOP to opt out.

After that, each update you post with Notify subscribers ticked is one text with the page, the incident, its phase and a link, at most two SMS segments long:

[Acme Cloud] Elevated error rates on checkout: investigating. https://app.ziplogger.ai/status/acme-cloud Reply STOP to opt out.

Replying STOP removes the number. On your own Twilio account, that reply reaches ZipLogger through the number's incoming-message webhook, https://app.ziplogger.ai/api/v1/notifications/twilio/sms, the same one that takes acknowledge replies to on-call pages (the SMS paging post has the setup).

A public form that sends texts is what SMS pumping fraud looks for: a script submits thousands of premium numbers and you pay for the confirmations. So confirmation texts are capped at 20 per page per hour and 200 per workspace per day, on top of the usual limit per address. The Subscribers tab shows SMS numbers masked.

The page also links an RSS feed of the latest 50 published incidents:

https://app.ziplogger.ai/api/v1/status-pages/public/acme-cloud/feed.rss

On a password-protected page, the RSS link shown after unlocking carries the visitor's access token, so a feed reader can use it. Like the unlock itself, it stops working after 30 days or when the password changes.

For a README or your own website, the Status badge card on the Settings tab gives a small SVG badge ("status | operational", coloured by state) with Markdown and HTML snippets to paste. Badges are only served for pages anyone can see: a page with a password or an IP allowlist has no badge.

Your brand on it

On plans with custom branding (Team and above), the page shows your workspace's name, logo and primary colour. The "Powered by ZipLogger" line at the bottom is removed only with white label, on Business and Enterprise.

Limits

What it does not do yet

• Custom domains (status.yourcompany.com) are not available yet. The page lives on app.ziplogger.ai/status/....
• No sign-in-only pages: access is by password, IP allowlist or both, not by your company's single sign-on.
• No Microsoft Teams subscribers.
• SMS STOP replies work through Twilio only, not Telnyx.
• One language per page, the one you write in.

Next step

Create your first page under Alerts → Detection → Status pages, or read the status page docs for the full reference.