Website reliability
Website status and uptime checks for business services
Track web properties, SSL/status logs, and public status pages from the same IT operations platform.
Backed by app modules
- Workflow
- What teams can do here
- Step 1
- Add website monitors
- Step 2
- Review status logs
- Step 3
- Share public status when needed
- Step 4
- Use reporting for follow-up
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Website availability checks
SSL and status logs
Public status page support
History for incidents and reviews
How it works
- 01
Add a monitor
Create a monitor and pick its type: HTTP or HTTPS, TCP port, ping, DNS records, domain registration expiry, cron heartbeat, a multi-step API flow, or a browser synthetic check. Set the check interval, timeout and the status code you expect back.
- 02
Check on a schedule and log every result
A scheduled task runs each active monitor and writes a check log with the result, status code and response time. For HTTPS monitors it also inspects the certificate and records the SSL expiry date and issuer so you are warned before a certificate lapses.
- 03
Confirm before declaring an outage
A monitor only flips to offline after a configurable number of consecutive failures, and up and down transitions are recorded as status logs that calculate the exact downtime duration. Maintenance windows suppress transitions and alerts during planned work.
- 04
Alert, escalate and open tickets
Alerts cover down, recovery, SSL expiry, slow response, DNS change, missing keyword and domain expiry. They can fan out to email, Slack, Teams and generic webhooks, run timed escalation steps, and optionally open a support ticket linked to the related asset.
- 05
Publish a status page
Group monitors onto a public status page with a slug and brand colour, post incident updates on a timeline, let visitors subscribe by confirmed email, and offer an RSS feed so customers can follow status without contacting support.
A worked example
Say a D2C e-commerce brand watches 25 endpoints: storefront, checkout API, payment webhook, DNS records and the domain's registration. The checkout monitor expects a 200 and the word "order" in the body, checked every minute. One evening the API starts returning 502s; after its configured three consecutive failures it flips offline, a status log starts counting downtime, and email plus Slack alerts fire with the runbook text attached. An escalation step pages the lead when nobody acknowledges, a linked ticket opens, and the public status page carries an incident update — so support can say "we know, fix in progress" instead of guessing.
Already live in the product
- Backed by app modules
- Running in production today: website status checks, status logs, and public status pages.
- Protected app route:
- /website-status
Frequently asked questions
See also: Guide: server monitoring tools compared · Guide: network monitoring tools compared · Server monitoring · Helpdesk & ticketing · Pricing
Hear about downtime from your monitor, not your customers
Confirmed-failure checks across HTTP, DNS, ports, heartbeats and real browsers — with escalations, auto-tickets and a public status page that keeps everyone in the loop.