The percentage of time a website or service is accessible and responding correctly. It's calculated as: (total time − downtime) ÷ total time × 100.
Uptime is typically expressed as a "nines" figure. 99% uptime sounds high, but it allows over 87 hours of downtime per year. 99.9% allows ~8.7 hours. 99.99% ("four nines") allows only ~52 minutes.
Example: If your site was down for 4.4 minutes in a 30-day month, your uptime was 99.99%. AmAzE Uptime calculates this automatically on your monitor's detail page.
Any period during which a website or service is unavailable, returning errors, or not responding within the configured timeout. An uptime monitor records each downtime event as an incident with a start timestamp, end timestamp, and total duration.
Downtime can be caused by server errors (5xx responses), DNS failures, network connectivity issues, firewall blocks, certificate errors, or application crashes.
Example: Your server returns HTTP 503 at 14:32. AmAzE Uptime records the incident, sends you an email alert, and keeps checking. At 14:41 the server returns 200 - the incident is closed with a 9-minute duration and you get a recovery notification.
The frequency at which an uptime monitor sends a check request to your endpoint. Shorter intervals catch problems faster but require more infrastructure resources.
Common intervals are 1 minute, 5 minutes, 10 minutes, 15 minutes, 30 minutes, and 60 minutes. The difference between a 1-minute and 5-minute interval is significant: a 5-minute interval means you could be unaware of an outage for up to 5 minutes before the first alert fires.
AmAzE Uptime: Free plan checks every 5 minutes. Pro and Max plans unlock 1-minute intervals for the fastest possible incident detection.
A digital certificate that encrypts the connection between a browser and a web server, enabling HTTPS. SSL certificates are issued by a Certificate Authority (CA) and expire on a fixed date - typically after 90 days (Let's Encrypt) or up to 1-2 years (commercial CAs).
An expired SSL certificate triggers browser security warnings ("Your connection is not private") and may block access entirely, making it just as damaging as a server outage. SSL monitoring alerts you days or weeks before expiry so you can renew in time.
AmAzE Uptime SSL monitoring: Checks certificate validity on every HTTPS monitor. You set a threshold (e.g., 14 days) and receive an email alert when the certificate is due to expire within that window.
A three-digit number returned by a web server in response to an HTTP request, indicating the outcome of the request. Status codes are grouped into five classes:
1xx Informational · 2xx Success (200 = OK) · 3xx Redirects (301 = Moved Permanently) · 4xx Client errors (404 = Not Found) · 5xx Server errors (500 = Internal Server Error, 503 = Service Unavailable)
Uptime monitors typically treat any 2xx response as success and anything else (or no response) as a failure. AmAzE Uptime records the exact status code returned during every incident.
Example: Your checkout page starts returning HTTP 500 after a bad deploy. AmAzE Uptime detects this within 60 seconds, records "HTTP 500" in the incident log, and sends you an alert with the full response body.
The time elapsed from when a monitor sends an HTTP request to when it receives the complete response from the server. Measured in milliseconds (ms). Also called "latency" or "TTFB" (Time To First Byte) in some contexts.
Response time is an early-warning signal. A server whose response time suddenly increases from 200ms to 2,000ms is probably under severe load - and a full outage may follow. Monitoring response times over time also helps you identify slow pages and measure the impact of deployments.
AmAzE Uptime: Pro and Max plans record response times for every check and display them as interactive charts on your monitor's detail page, with 24-hour, 7-day, and 30-day views.
The maximum time a monitor will wait for a server response before treating the check as a failure. If no response is received within the timeout window, the check is recorded as a timeout incident.
Setting the timeout too low produces false positives on genuinely slow pages. Setting it too high delays incident detection. A timeout of 10-15 seconds is suitable for most websites. APIs and health-check endpoints often warrant 5 seconds.
AmAzE Uptime: Each monitor has a configurable timeout between 5 and 30 seconds. The default is 10 seconds.
A recorded period during which a monitor's checks consistently fail. An incident begins when a check fails and ends when subsequent checks return to normal. The incident log stores the full context: start and end timestamps, total duration, HTTP status code, response body (on failure), response headers, and the alert emails sent.
Having a full incident log with HTTP details is crucial for root-cause analysis. "The site was down for 8 minutes" is useful; "The site returned HTTP 503 with body 'Database connection refused' for 8 minutes" is actionable.
AmAzE Uptime: Every incident is stored indefinitely and viewable on your monitor's detail page. Expanding an incident row shows all recorded HTTP details.
A publicly accessible web page that shows the real-time and historical operational status of a service or collection of services. Status pages allow customers to check service health themselves rather than filing support tickets - reducing support load during incidents.
A well-designed status page shows current status (operational/degraded/outage), a 30-day incident history, and optionally response time charts. When an incident occurs, the status page updates automatically.
AmAzE Uptime offers two types: A global status page at a custom URL listing all your public monitors; and per-monitor status pages with randomly generated private URLs - shareable with specific clients without exposing your full dashboard.
A mechanism for one system to notify another of an event by sending an HTTP POST request to a pre-configured URL. Unlike polling (where your system asks "did anything happen?"), webhooks push notifications immediately when an event occurs.
In uptime monitoring, webhooks allow you to route alerts into any system that accepts HTTP requests: Slack, Teams, PagerDuty, Discord, your own API, a Zapier/Make automation, or a custom script. The payload is a JSON body describing the event.
AmAzE Uptime (Max plan): Configure up to 10 webhook endpoints. Choose which events each endpoint listens to: monitor.down, monitor.up, monitor.ssl_expiring, monitor.ssl_error. Each request is HMAC-SHA256 signed for security verification.
Hash-based Message Authentication Code. A cryptographic technique that uses a shared secret key and a hash function (e.g., SHA-256) to produce a signature for a message. The signature lets the recipient verify both that the message came from the expected sender and that it was not modified in transit.
In webhook security, HMAC is used to sign the request body. The sender computes HMAC-SHA256(secret, body) and includes the result in a header. The receiver recomputes the same value and compares - if they match, the webhook is genuine.
AmAzE Uptime: Every webhook includes the header X-Amaze-Signature: sha256=<hex>. Your endpoint computes the expected signature using your webhook's secret key and compares it to reject forged requests.
Service Level Agreement. A formal commitment - often between a SaaS company and its customers - to maintain a specific level of service availability, usually expressed as a minimum uptime percentage (e.g., "99.9% monthly uptime").
SLA tracking answers the question "are we meeting our commitments?" An SLA of 99.9% allows approximately 43.8 minutes of downtime per month. Breaching the SLA may trigger service credits or other contractual consequences.
AmAzE Uptime (Pro/Max): Response time charts include a calculated uptime percentage for the displayed period. You can show this percentage on your public status page to demonstrate SLA compliance to customers.
A scheduled period during which monitoring alerts are suppressed. Maintenance windows prevent false-positive alerts during planned outages such as deployments, database migrations, or infrastructure updates.
Without maintenance windows, every deployment that briefly takes your site offline triggers an alert email - creating alert fatigue and training your team to ignore notifications.
AmAzE Uptime: Set a maintenance window with a start time and duration. Checks still run during the window, but no alerts are sent. The window appears in your monitor's detail view. Available on all plans.
Domain Name System. The internet's "phone book" - it translates human-readable domain names (e.g., mysite.com) into IP addresses that servers use to communicate. DNS failures can make a site completely unreachable even when the web server itself is running perfectly.
A DNS failure manifests as a "connection refused" or "could not resolve host" error in your uptime monitor's incident log - different from an HTTP error, where the server responded but with an error code.
AmAzE Uptime: DNS resolution failures are detected during checks and recorded in the incident log with a clear error message, so you can distinguish between "server error" and "DNS propagation issue."