Give visitors one place to check service status
When a website slows down, visitors want to know whether the problem affects the service and what happens next. An internal monitoring dashboard helps you investigate. A public status page gives customers and colleagues a clear, deliberately selected view of availability, incidents and planned maintenance.
With MetriBeacon, you can prepare a status page privately, choose the monitoring sources you want to share and publish updates explicitly. This guide explains how to create a useful page without exposing internal details or turning incomplete observations into reassuring uptime numbers.
Choose components visitors recognise
Start with the services people actually use. A small project might need just Website and API. A larger service could separate sign-in, file uploads and background processing when those functions have their own meaningful observations.
These are example labels, not a suggested configuration for every project. Avoid publishing internal hostnames, IP addresses or database names simply because they are familiar to your team. A visitor should understand which function is affected without understanding your infrastructure.
Give each component a clear purpose. A successful homepage request does not prove that an upload works. If you only observe one HTTP endpoint, describe that scope honestly. The website monitoring guide explains how to choose a useful URL; the API monitoring article covers response checks for public APIs.
Create and review a private status-page draft
Open Status pages, where available in your account, and begin with a private draft. The status-page documentation describes the controls and publication flow.
- Choose a stable URL name and a public page title.
- Set the language and time zone for your intended audience.
- Add recognisable components and organise related services.
- Select and approve each monitor or measurement series you intend to share.
- Decide separately whether its historical data should be public.
- Review the preview, then publish the page explicitly.
A page uses an address such as metribeacon.com/status/your-service. Here, “your-service” is a placeholder for your chosen URL name. Use a name you can keep when the underlying server or deployment changes.
Treat the preview as a visitor's view. Check component labels, measurement names, units, descriptions and any public explanation. A technically correct value may still reveal a customer name or an internal operating detail. New monitors are not automatically added to your public page, so review its scope when your service changes.
Read uptime from known observations
An uptime percentage is useful only when its observation period is clear. In MetriBeacon, unknown or unobserved time does not automatically count as healthy. Availability relates successful known time to the time that can actually be evaluated.
For an illustrative example, suppose a component has two hours of evaluable observations and six minutes of confirmed downtime. Its availability for that observed period is 95 percent: 114 successful minutes divided by 120 evaluable minutes. That does not establish availability for the rest of an unobserved day.
Keep three questions separate:
- Is the component currently reporting a healthy state?
- What availability does the recorded history support?
- Are observations recent enough to support the conclusion?
Public daily history uses UTC day boundaries. Check the meaning of the displayed period before comparing it with a locally timed incident. A job outcome or a device check-in is also a different kind of evidence from continuous service availability. The heartbeat monitoring article explains missing contact and stale measurements.
Publish incident updates that answer practical questions
Internal alarms are not automatically public incident reports. Prepare a separate incident draft, choose the affected components and publish it deliberately. This gives you a chance to explain the customer impact while leaving internal logs, credentials and diagnostic details private.
A useful first update answers four questions: what is affected, what users might notice, what is being done and when another update is expected. Use facts you can support. Avoid promising a recovery time when the cause or remedy is still uncertain.
For example, an explicitly fictional update could read:
Some API requests are delayed. We are investigating elevated response times. The website remains accessible. We will provide another update by 10:30.
The time in that example is an editorial commitment, not an automatic update feature. Choose a deadline your team can meet. Subsequent updates should explain meaningful changes, and the closing report should state what recovered and whether users need to retry an operation.
A green measurement and a published explanation serve different purposes. Confirm the affected function has recovered before closing an incident; a single unrelated successful check does not settle the impact.
Announce maintenance before visitors encounter it
For planned work, publish a maintenance report with its expected period, affected components and likely user impact. Explain whether the service will be unavailable, intermittent or simply slower, and what visitors should do during that time.
Public maintenance communication and internal alarm handling need their own decisions. Do not assume that writing a public notice changes your notification rules. Review any internal maintenance or muting settings separately and check fresh observations after the work.
Keep the report current if the window changes. An expired “planned maintenance” message is confusing when the service remains impaired. Publish an update and a clear completion report when the work is finished.
Offer updates and keep publication responsibility clear
Enable the feeds or subscription channels you want to offer. Email subscribers confirm their address and can unsubscribe through their private link. Test the visitor journey before relying on subscriptions as part of incident communication.
If you use your own status domain, follow MetriBeacon's displayed ownership and host-mapping steps before announcing its HTTPS address. For an example of a public page, visit the MetriBeacon platform status page.
Where several people maintain the page, distinguish editing from publishing. Status-page editors prepare content; publishers release it within approved sources. These page roles do not grant general access to other workspace data.
During a temporary service problem, visitors may see a labelled older snapshot. Read that label and its timestamp rather than presenting the snapshot as a current live measurement.
Frequently asked questions about status pages
Does a status page replace monitoring alerts?
No. Alerts help the responsible person investigate a configured condition. A status page communicates selected service information to visitors. Use alarms and notifications alongside clear public updates.
Can I publish all my monitoring data automatically?
Select and approve the sources intended for visitors, and approve history separately. Keep private identifiers and operational details out of public names and reports. Expanding internal monitoring does not automatically expand the page.
Is a gap in history proof of an outage?
No. A gap means that the period lacks reliable observations. It should not become invented healthy time or an unsupported claim of confirmed downtime. Check the source, timestamps and monitoring state.
Can I withdraw a published page or source?
Yes. Withdrawing a source removes its public history; withdrawing the page stops its public outputs. Review the scope carefully before sharing links with visitors.
Start with one service and a clear public story
Create a free MetriBeacon account, connect an important service and prepare a small status-page draft where the feature is available. Review exactly what a visitor will see, publish it deliberately and practise one incident update before you need it under pressure.
MetriBeacon is free within its documented technical quotas. The Website/API template below helps you create an HTTP monitoring source for your service. You then select and approve the information for your status page as a separate step.
