Uptime monitoring and alerts

What you will learn #

Use this chapter to add a monitor for a website endpoint, read its current status and history, choose who receives alerts, and understand maintenance windows and recovery actions. A monitor checks a URL or service endpoint from selected monitoring locations. It complements visitor analytics: it checks reachability and configured response conditions, not whether a person can complete a purchase or use every part of your site.

Before you begin #

• Sign in to Hitsteps and select the website you want to monitor. The monitor belongs to that website.
• The dashboard exposes an Uptime Monitor section. Source identifies the monitor controls as owner-level. Confirm the account role can open and edit them before following these steps.
• Check the current plan allowance and in-product quota before adding monitors. The overview displays the plan, monitor allowance and daily alert-credit use. If your plan has no monitor allowance, use the displayed plan comparison; do not assume Free includes a monitor.
• If you need email or phone alerts, first verify the contact address or number. Email, phone, browser and mobile app delivery depend on the chosen contact method and its current availability.
• For HTTP content checks, choose a stable phrase that is present in the expected response. For authenticated endpoints, have the endpoint's credentials available to the person configuring it. Never paste credentials into support messages or public documentation.
• If a firewall restricts inbound checks, an administrator may need to allow the monitoring addresses shown under Scanner IPs in the dashboard. Copy the current values from your own account; they can change.

Where to find it #

From the signed-in dashboard, select Uptime Monitor → Uptime Overview. The corresponding site-scoped URL pattern is /stats/<your-site-id>/uptime/.

The uptime workspace has these areas:

• Monitors: overview, add and edit monitors, and a monitor's detail/history page.
• Contacts: recipients and their alert schedules and thresholds.
• Maintenance: planned windows for a selected monitor.
• Recovery Actions: optional actions associated with monitor events.
• Scanner IPs: current monitoring addresses to allow through a firewall when needed.

Use Add monitor from the workspace, or Uptime Monitor → Add new monitor in the dashboard menu. Do not use a numeric site ID copied from an example; each site has its own route.

Step by step #

1. Open Uptime Monitor → Uptime Overview and choose Add monitor.
2. Give the monitor a name that identifies the service, such as Storefront home page. Enter the endpoint address you want checked. Use an endpoint you control and make sure its certificate and redirect behavior match the options you choose.
3. Choose what to check. The monitor form can offer HTTP(S), MySQL, FTP, SSH, SMTP, POP3, IMAP, ICMP ping and a custom port. Choose the check that matches the service you intend to monitor. A port check tests service reachability; it does not sign in or verify that the application is usable.
4. For an HTTP(S) check, you can set Contains or Does not contain and enter a short expected or forbidden response phrase. This can help detect an error page that still returns a successful HTTP response. Do not use a phrase that changes often. The content condition does not apply to ordinary port checks.
5. Set the check interval and timeout that fit the endpoint. The source form accepts minute intervals from 1 through 60 and timeout values from 1 through 60 seconds. The inspected form defaults both values to 5. Confirm the live units and values before saving.
6. If the endpoint requires HTTP Basic Authentication, enter credentials in the protected dashboard form. Decide whether redirects should be followed and whether certificate validation should be bypassed. Leave certificate validation enabled for ordinary HTTPS checks; bypassing it weakens the check.
7. Select monitoring locations. The current save validation requires at least two locations. Use the default location set unless you have a reason to compare regions. A selected set can help show regional differences; it does not guarantee every visitor's route is tested.
8. Choose whether to show confirmed up/down incidents as annotations on the site's traffic charts. Select the contacts and recovery actions to associate with this monitor, if already configured. These associations do not create the contact or action.
9. Save the monitor. Return to Monitors and wait for completed checks. A new monitor can show Awaiting status until a check has completed. Do not interpret that state as an outage.
10. Open the monitor's details to review the current state, last check, configured interval, observed availability when enough checks are present, coverage, confirmed incidents, response-time chart and latest events.
11. If you need to stop checks temporarily, edit Monitor Status and choose Pause. Reactivate it when maintenance ends. Paused monitors do not have checks expected, so their status is not evidence that the endpoint is healthy.
12. To change alert delivery, create or edit contacts, then edit the monitor and associate the intended contacts. Configure maintenance separately for expected downtime. Associate a recovery action only after its connection has been validated and its effects reviewed.

Configure a contact

1. Open Contacts and add a contact with a recognizable name.
2. Select one of the contact methods currently offered: email, SMS, voice call, SMS plus voice, or web and mobile push. The code labels email and push as free, and shows credit costs for phone channels. Phone options are disabled for trial or free accounts in the inspected source; recheck current account eligibility and charges in the dashboard before choosing one.
3. Enter the email address or phone number and complete the verification step. For push, choose the account user who should receive it and make sure that user has an applicable mobile app or supported browser push subscription. A browser notification can also depend on the dashboard or extension being available.
4. Choose the alert schedule: always, daily hours, selected days of the week, or a custom date range. Review the displayed account timezone and start/end times.
5. Set how many repeated failures should pass before notifying this contact and how many monitoring servers must report the error. The inspected form defaults to 5 failures and 2 servers; its source validation accepts 1 to 30 for each value, subject to the available server count. These settings reduce alerts from brief or isolated failures. They are alert filters, not a guarantee that an incident will be detected at a particular time.
6. Enable Notify when fixed if the contact should receive a recovery notification. Save and verify the contact before associating it with monitors.

Add a maintenance window

1. Open Maintenance and add a schedule.
2. Name the window, select the monitor, and choose daily hours, selected days of the week, or a custom date range.
3. Set the start and end time or dates. Confirm the account timezone and the affected monitor before saving.
4. Verify the schedule appears in the maintenance list. A schedule is associated with a specific monitor; create separate schedules for other monitors that need the same window.

Recovery actions require extra care

The Recovery Actions area includes SSH commands, HTTP requests, and DNS failover through Cloudflare in the inspected source. These actions can change a real server or route traffic to a different address.

• Read the current warning and validate the connection before associating an action with a monitor.
• SSH uses public-key authentication. Add only the generated key shown in the dashboard to an account with the minimum required permissions. Review every downtime and recovery command with a server administrator. Do not use an untested command on production.
• HTTP actions call endpoints that you provide. Confirm the endpoint's authentication, allowed methods, logging and side effects before enabling it.
• DNS failover currently lists Cloudflare in the dashboard. Verify the selected zone and A record and the downtime and recovery IP addresses with the domain owner. A DNS change can affect all visitors and may take time to propagate.
• Use a maintenance schedule to prevent expected changes from being treated as incidents where appropriate. It does not make an unsafe recovery action safe.

Worked example #

For a fictional site, store.example, an owner could create a monitor named Storefront home page for https://store.example/, select two or more available monitoring locations, and set an expected phrase that is stable on the page, such as Welcome to our store. They could add a verified email contact and choose a reasonable failure delay before notification.

After the first completed check, the monitor should show a confirmed Up or Down state, a last-check time, and its configured interval. If no completed check has established a state yet, expect Awaiting status. If checks stop arriving, the state may become Checks delayed and the last known state may be shown as stale. A real outage or recovery should appear in the event history after it is confirmed. These are illustrative outcomes, not a promise about timing or uptime.

Controls and metrics #

The monitor type menu also includes HTTP(S), MySQL, FTP, SSH, SMTP, POP3, IMAP, ICMP ping and custom-port checks. A network/service check confirms only the configured endpoint or port's response; it does not test a complete user journey. For HTTP(S), the form additionally exposes response text conditions, redirect handling, optional SSL verification bypass and Basic Authentication fields.

The overview also summarizes plan allowance and daily alert credits. Check the live labels for the current account's quota and usage; limits and prices can differ by plan and can change.

Problems and fixes #

• Awaiting status after setup: wait for a completed check and refresh the monitor. Confirm the address and selected locations. Do not count the initial wait as downtime.
• Checks delayed: treat the previous state as stale. Check whether the endpoint is reachable and whether a firewall blocks the current addresses listed in Scanner IPs. Verify the monitor interval, timeout and selected locations.
• The monitor reports down although the page opens in your browser: compare the exact URL, port, redirect and certificate settings. Check whether the endpoint responds from the selected regions and whether the required response phrase or condition is still present.
• False alert for a short interruption: review the contact's failure delay and server-confirmation count. Adjust only after deciding how much detection delay is acceptable.
• No notification: confirm the contact is verified, selected for that monitor, inside its alert schedule, and configured for the desired recovery notice. For push, confirm the selected user has an active supported subscription. For phone methods, check account eligibility and available credits.
• Cannot add a monitor: inspect the plan allowance and monitor count shown in the overview. The account may not include another monitor or may require an eligible plan.
• Cannot add an SMS or voice contact: the inspected form disables phone methods for trial/free status and assigns phone methods alert credits. Check the current account plan and in-app terms before making changes.
• Expected downtime still raises an alert: check that the maintenance schedule names the correct monitor and covers the correct times and dates in the account timezone. A contact's own alert schedule is a separate control.
• Recovery action did not run or caused an unexpected change: disable the association after assessing the impact, inspect the action's validation and event history, and involve the server or DNS administrator. Do not repeatedly retry a command or DNS change without checking its current effect.

Access, privacy and limits #

• Uptime monitoring is scoped to a selected website and can store the endpoint URL, monitor configuration, response/check history, incident details, contacts and recovery-action configuration. Treat URLs as potentially sensitive if they contain tokens or private paths; use an endpoint without secrets in its address.
• Basic Authentication values, phone numbers, email addresses, account push recipients, Cloudflare credentials, HTTP endpoints and SSH commands are sensitive. Give access only to the people who need it; never include them in public screenshots, shared examples or support posts.
• Monitor management is an owner-level workflow. Use your account’s displayed permissions and effective retention; ask the owner or support if the monitor or history you need is unavailable.
• Monitor allowances, check/alert credits, contact method eligibility and plan names are account-dependent. The inspected source does not establish current free-plan inclusion or live quotas. Confirm against the account and current plans and feature list; do not assume every account has every channel.
• SMS and voice alerts use in-product credits in the inspected source. Confirm current pricing, availability and credit use before enabling them. This guide does not authorize purchases or account changes.
• The monitor's availability and response-time figures reflect its checks and coverage. They are not a contractual uptime SLA and do not establish that a complete page, checkout or third-party dependency works for every visitor.
• Monitoring locations and IP addresses can change. Read Scanner IPs in the signed-in dashboard when configuring firewall rules.
• Use the supported alert channels shown by your monitor. For integrations, use the documented public APIs rather than attempting to use a dashboard alert receiver.

Related help #

• Uptime monitoring feature overview
• Plans and feature list
• Hitsteps support FAQ
• Hitsteps manual home
• Getting started and installation
• Dashboard and reports
• Integrations and mobile

• For product questions not answered here, use the support contact path linked from the support FAQ.

• All guide topics

• Frequently asked questions
• Contact support
• Privacy, data controls and tracking exclusions
• Developer APIs and reporting connectors

Last checked #

Checked 8 November 2026 using product documentation and source, with public pages and safe sample screens where available. Account-specific access, provider controls and effective limits can differ; use the current message shown for your website. Examples are illustrative.