Service Status

Monitoring the services customers actually use

The status dashboard is designed around the customer journey rather than a single server light. A website visitor may depend on DNS, the hosting node, SSL delivery, the application runtime and the client portal at different times. A broadcaster may depend on an AzuraCast or radio node, stream delivery and the website or app that exposes the player. Video customers have another chain that can include ingest, processing, HLS playback and storage. Monitoring those layers separately makes incident communication more useful because an outage can be narrowed to the part of the platform that is actually affected.

How to read the status cards

Each monitor identifies the service, the public hostname used for operational reference, the region, the current response-time indicator and the rolling uptime figure published in the status feed. The animated history strip gives a quick visual summary of recent health. Green represents normal service, amber represents a period of degraded performance, and red is reserved for a major service interruption. Response time is useful as a trend, but it should not be treated as a guaranteed end-user speed because customer location, routing, ISP performance and the application itself can all influence real-world latency.

Why separate cPanel, VPS, cloud and media infrastructure

A cPanel website account is not the same workload as a virtual private server or a live media platform. cPanel hosting is optimised around websites, email, databases and familiar account-management tooling. VPS and cloud services introduce isolated compute, persistent processes and operating-system control. Radio and video platforms depend on streaming-specific software and network behaviour. Publishing each category as its own monitor makes the status page more transparent and avoids presenting a single green badge as proof that every product is healthy.

Incident communication and maintenance

If a service issue is confirmed, the incident area is the place to publish the affected component, the start time, the current impact and the most useful next update. Scheduled maintenance should be announced separately from unexpected incidents so customers can distinguish planned work from a fault. Updates should remain concise and factual: what is affected, what is not affected, what the operations team is doing, and when another update will be posted. A resolved incident should remain visible long enough for customers to understand what happened rather than disappearing the moment the service returns.

When to open a support ticket

A green status page does not mean an individual account can never have a local problem. If the monitor is operational but your own website, stream, VPS or control panel is not behaving normally, collect the exact hostname, the time of the test, the error message and the action you were trying to complete. Test from more than one network where practical and avoid sending passwords, API keys or stream credentials in screenshots. That information helps support distinguish an account-specific issue from a wider platform event and usually shortens the path to a useful diagnosis.

Built for future monitoring integration

The page reads from a small JSON-backed status feed, which keeps it compatible with standard cPanel hosting and simple PHP deployments. The same feed can later be updated by a cron job, external uptime provider or internal monitoring system without rebuilding the front-end design. That means the presentation layer can stay consistent while the data source becomes more sophisticated. The goal is a status page that looks polished, communicates clearly and can evolve into a true operations dashboard as monitoring automation expands.