Status page wording and examples
A status page is read by customers in a hurry. Name things the way they think about your product, and keep every line short enough to scan.
Templates
Replace the parts in [brackets].
Page description
The line under the page title.
Live status of [product]. We check every service around the clock and post updates here during incidents and planned maintenance.
Groups and components
Name components after what customers use.
Website - Marketing site - Dashboard API - REST API - Webhooks Payments - Checkout - Invoices Third-party - Email delivery - SMS
Subscribe prompt
Next to the subscribe form.
Get an email when we post an incident or plan maintenance. Choose only the services you use. You can unsubscribe from any email.
What each status means
For a help page or the page footer.
Operational: working normally. Degraded: working, but slower or with some errors. Major outage: not working for most people. Under maintenance: planned work is in progress; see the notice for what is affected.
Where to get help
The page footer.
Something wrong that isn't listed here? Contact [support address] and include the time and what you saw.
Writing tips
- Use your customers' names for things. "Checkout" means something to them; "payments-svc-eu" does not.
- Keep the list short: ten components people care about beat forty internal services.
- List the providers you depend on, so a vendor outage has a place to be reported.
- Only show components backed by a real check, so a green light means something.
In OpenUptime
- Each component on a status page is a monitor, so its state comes from real checks.
- Group components under headings you choose, and hide the ones you only want to watch internally.
- Readers can subscribe by email to the whole page or to the components they use, and follow the RSS feed.
Publish these on a status page
Status pages, incident updates and subscriber emails are included on the Free plan. No card needed.
Questions
What should a status page include?
The components customers use, their current state and recent uptime, active incidents with their updates, planned maintenance, a way to subscribe, and how to reach support.
Should I show internal services on my status page?
Usually not. Show what customers use and fold internal services into those components. A failing internal service shows as the customer-facing feature it breaks.
Should third-party services be on my status page?
Yes, when customers would notice their outage, such as email delivery or payments. It tells people the problem is known even when the fix is not in your hands.
状态页文案与示例
状态页的读者通常很着急。按照用户理解产品的方式命名，每一行都短到可以一眼扫完。
模板
替换 [方括号] 中的内容。
页面说明
页面标题下方的一句话。
[产品] 的实时运行状态。我们全天候检查每一项服务，故障和计划维护期间会在这里发布更新。
分组与组件
按用户使用的功能来命名组件。
网站 - 官网 - 控制台 API - REST API - Webhook 支付 - 下单支付 - 发票 第三方服务 - 邮件发送 - 短信
订阅提示
放在订阅表单旁边。
发布故障或计划维护时，你会收到邮件通知。可以只选择你使用的服务，每封邮件里都可以退订。
各状态的含义
用于帮助页面或页脚说明。
正常：一切运行正常。 降级：可以使用，但变慢或部分出错。 严重故障：大多数人无法使用。 维护中：计划维护正在进行，受影响范围见维护通知。
获取帮助
页面页脚。
遇到了这里没有列出的问题？请联系 [支持邮箱]，并附上发生时间和你看到的情况。
写作建议
- 用用户的叫法命名。“下单支付”对用户有意义，“payments-svc-eu”没有。
- 组件列表要短：十个用户关心的组件，胜过四十个内部服务。
- 列出你依赖的第三方服务，这样它们出故障时也有地方通报。
- 只展示有真实检查支撑的组件，这样绿灯才有意义。
在 OpenUptime 中
- 状态页上的每个组件都对应一个监控，状态来自真实的检查结果。
- 可以把组件放在自定义的分组标题下，并隐藏只想在内部查看的组件。
- 读者可以通过邮件订阅整个页面或只订阅自己使用的组件，也可以关注 RSS 订阅源。
常见问题
状态页应该包含哪些内容？
用户使用的组件及其当前状态和近期可用率、进行中的故障及更新、计划维护、订阅方式，以及联系支持的方式。
状态页要展示内部服务吗？
通常不需要。展示用户使用的功能，把内部服务归入这些组件。内部服务出故障时，就体现为它影响到的那个用户功能。
第三方服务要放到状态页上吗？
如果它们出故障时用户会有感知，例如邮件发送或支付，就应该放上去。即使修复不在你手里，也能让用户知道问题已被发现。