Uptime monitoring checks a website or endpoint at regular intervals to confirm that it is reachable and returning an acceptable response. When a check fails, monitoring creates a time-stamped event and alerts the responsible team according to the configured policy.
Effective uptime monitoring goes beyond asking whether the homepage loads. It checks the services customers actually depend on, uses intervals that match business impact and avoids sending alerts that nobody can act on.
Key takeaways
- Use HTTP checks for customer-facing web services.
- Monitor critical endpoints as well as the homepage.
- Define what a successful status code and response time mean for each endpoint.
- Select intervals according to customer impact.
- Confirm transient failures where appropriate.
- Treat response time and availability as related but separate signals.
What is uptime monitoring?
Uptime monitoring is an automated process that repeatedly checks whether a service is available.
For a website, the monitor usually sends an HTTP request and records:
- Connection success or failure.
- Status code.
- Response time.
- Timestamp.
- Redirect behaviour.
- TLS or certificate result.
- Alert state.
The monitor creates an external view of the service. This is valuable because it tests the path a customer may use rather than relying only on an internal server status.
How does an HTTP uptime check work?
An HTTP monitor follows a simple cycle:
- Send a request to the configured URL.
- Wait for a response within the timeout.
- Evaluate the response against success rules.
- Record the result.
- Trigger confirmation or alert logic when the result fails.
- Repeat at the configured interval.
A check may fail because of:
- DNS resolution.
- Network connection.
- TLS negotiation.
- Timeout.
- Unexpected status code.
- Redirect problem.
- Application error.
The recorded failure should provide enough evidence to begin investigation.
What counts as downtime?
Downtime should be defined before monitoring begins.
Common definitions include:
- No connection.
- Request timeout.
5xxserver error.- Specific
4xxresponse. - Invalid TLS connection.
- Unexpected redirect.
- Response time above a critical limit.
A 404 may be downtime for a monitored product page but expected for another test route. A 401 may be the correct response for an unauthenticated API check.
Success rules must reflect the endpoint’s purpose.
HTTP monitoring versus ping monitoring
HTTP monitoring tests the application layer. Ping monitoring tests whether a network host responds to ICMP traffic.
| HTTP monitoring | Ping monitoring |
|---|---|
| Tests a website or API response | Tests network reachability |
| Can inspect status codes | Does not understand HTTP |
| Can detect application failures | May succeed while the application is down |
| Uses the customer-facing protocol | May be blocked by network policy |
For websites and APIs, HTTP monitoring is usually the more meaningful outside-in check.
What should you monitor beyond the homepage?
Monitor the minimum set of endpoints that represents customer value.
Examples:
- Login page.
- Authentication API.
- Checkout.
- Booking.
- Search.
- Contact form endpoint.
- Core API.
- Customer dashboard.
- Public status page.
- File delivery route.
Use safe checks. Avoid synthetic actions that create orders, contact real customers or modify production data unless a controlled test environment and cleanup process exist.
How often should uptime checks run?
The interval should match business impact.
| Service | Example interval |
|---|---|
| Revenue-critical SaaS application | 30-60 seconds |
| Login or checkout | 30-60 seconds |
| High-value client website | 1 minute |
| Standard brochure website | 1-5 minutes |
| Low-impact informational page | 5 minutes |
A one-minute interval means a failure may begin just after a successful check and remain undetected until the next run. Alert delivery and confirmation checks add further time.
Shorter intervals improve detection speed but create more checks and may increase sensitivity to brief network events.
How do confirmation checks reduce false alerts?
A confirmation check repeats or validates a failed result before sending a critical notification.
This can reduce alerts caused by:
- A brief network interruption.
- A single slow response.
- A temporary DNS problem.
- A monitor-location issue.
- A short deployment transition.
Confirmation logic should not hide persistent intermittent faults. Record failed checks even when they do not trigger a full escalation.
What is response-time monitoring?
Response-time monitoring records how long the endpoint took to answer.
Track:
- Typical baseline.
- Repeated degradation.
- Difference between regions or times.
- Changes after deployments.
- Correlation with error rates.
- Whether the service crosses a customer-impacting threshold.
There is no universal response-time target for every endpoint. A lightweight status route and a complex report have different expected behaviour.
Use thresholds based on normal performance and customer expectations.
What causes intermittent downtime?
Intermittent failures can be harder to diagnose than complete outages.
Possible causes include:
- Load balancer health checks.
- One unhealthy application instance.
- Database connection exhaustion.
- Rate limits.
- Memory pressure.
- DNS inconsistency.
- Expiring upstream connections.
- Third-party dependencies.
- Deployment race conditions.
- Network routing issues.
Compare monitoring timestamps with application logs, deployment events and supplier status information.
Can a website return 200 and still be broken?
Yes.
An application may return 200 OK while displaying:
- A maintenance message.
- A database error inside the page.
- Empty data.
- A failed embedded application.
- A login loop.
- An application-level error object.
Sentinel checks status code and response time only – it cannot inspect response content, so a 200 response with broken content underneath won’t be caught. The practical workaround is a dedicated status or health-check route that returns a non-200 status when something internal is actually wrong.
How should redirect monitoring work?
Redirects are normal when they are intentional.
Monitor:
- Whether the final destination is approved.
- Whether the chain is unexpectedly long.
- Whether HTTP redirects to HTTPS.
- Whether a canonical hostname is used.
- Whether a login flow redirects correctly.
- Whether a retired domain redirects safely.
Unexpected redirects can indicate configuration mistakes, expired services or compromise.
How should uptime alerts be routed?
Route alerts according to ownership and severity.
A practical policy:
| Condition | Route |
|---|---|
| Single transient failure | Record or low-priority warning |
| Confirmed application outage | Technical responder |
| Prolonged outage | Technical lead and business owner |
| Client website outage | Assigned agency team |
| Repeated slow response | Engineering or hosting owner |
| Recovery | Same incident channel |
Send recovery notifications so responders know when the monitor sees the service return.
Sentinel lists email, Slack, Microsoft Teams, Discord, SMS, phone and webhook alerting, with plan-specific availability.
What information should an alert include?
An actionable alert should contain:
- Monitor name.
- Affected URL.
- Failure type.
- Status code or error.
- Response time.
- Detection time.
- Number of failed checks.
- Link to monitor history.
- Assigned owner or runbook.
- Environment.
Consistent naming matters when a team monitors many client or application endpoints.
How should planned maintenance be handled?
Planned maintenance should be documented in the availability policy.
Options include:
- Pause alerts during an approved window.
- Keep checks running but suppress escalation.
- Use a maintenance status.
- Exclude agreed windows from internal reports.
- Continue external checks to confirm restoration.
Do not silently exclude maintenance from customer-facing SLA calculations unless the agreement permits it.
How is uptime calculated?
Uptime is usually expressed as:
available time ÷ total measured time × 100The result depends on:
- Measurement period.
- Check interval.
- Failure confirmation rules.
- Planned-maintenance treatment.
- Partial degradation rules.
- Geographic scope.
- Monitoring perspective.
Two providers can report different percentages for the same service if their methods differ.
For practical downtime examples, read What does reliable uptime mean for your business?.
How do you investigate an uptime alert?
- Confirm whether customers are affected.
- Review the exact error and monitor history.
- Check DNS and certificate status.
- Check recent deployments.
- Check application and infrastructure logs.
- Check third-party providers.
- Assign an incident owner.
- Restore service.
- Record cause and impact.
- Add or adjust monitoring when a gap is identified.
Avoid making multiple uncontrolled changes at the same time. Preserve enough evidence to understand the incident.
Uptime monitoring for digital agencies
Agencies should:
- Use consistent client and environment names.
- Group monitors by client.
- Assign per-client contacts.
- Record registrar and hosting ownership.
- Include monitoring scope in maintenance agreements.
- Define client communication thresholds.
- Review removed or migrated websites.
See Website Monitoring for Agencies.
Uptime monitoring for SaaS teams
SaaS teams should prioritise:
- Main application.
- Login.
- Core APIs.
- Payments.
- Customer dashboard.
- Critical third-party dependencies.
- Scheduled jobs.
- Status communication.
See SaaS Monitoring Without a DevOps Team.
Uptime monitoring checklist
- Define what success means for every endpoint.
- Monitor customer-critical routes.
- Select intervals by business impact.
- Set realistic timeouts.
- Configure confirmation logic.
- Monitor response time separately from outage state.
- Use consistent monitor names.
- Assign owners.
- Test alert channels.
- Document maintenance handling.
- Retain incident evidence.
- Review repeated failures.
- Add checks after incident reviews.
Frequently asked questions
What is a good uptime percentage?
It depends on customer needs, contracts and the cost of redundancy and response. The percentage should be defined with a clear measurement method.
Does a one-minute check interval detect downtime immediately?
No. Detection may take up to the interval, plus confirmation and notification time.
Should every failed check trigger an alert?
Not always. Confirmation can reduce noise, but critical services may need faster escalation. Match the policy to impact.
Can uptime monitoring test an API?
Yes, for status code and response time. Sentinel cannot send authentication credentials or headers, so only publicly reachable endpoints – or a dedicated public status endpoint – can be meaningfully checked.
Does uptime monitoring replace application logs?
No. Monitoring detects the symptom from outside. Logs and other telemetry help explain the internal cause.
Does Sentinel monitor response time?
Sentinel’s homepage states that its HTTP checks monitor uptime, status codes and performance against expected thresholds, and that its dashboard provides trended logs, uptime percentages and check histories.
Detect failures before customers report them
Good uptime monitoring combines meaningful endpoints, appropriate intervals and useful alert routing. Start with the services that affect access and revenue, then use incidents to improve coverage.
Monitor uptime and response performance from an external customer perspective.
View Sentinel pricing.