Uptime monitoring for DevOps teams

GET https://api.example.com/health
DNS 12 ms · TCP 18 ms · TLS 31 ms · TTFB 142 ms
HTTP/2 200 · body contains "status":"ok"
Retry from 2nd location: not needed

DevOps teams already collect plenty of signals: metrics, logs, traces, dashboards for every cluster. Yet the most common way an incident is first discovered is still a user or a colleague asking “is it down?”. Internal telemetry is excellent at explaining a failure and surprisingly poor at noticing that the outside world cannot reach you – a broken DNS record, an expired certificate, a misconfigured load balancer or a CDN outage all look healthy from inside. External uptime monitoring is the cheap, simple layer that answers the user’s question directly.

Catch incidents before your users do

The goal of uptime monitoring in a DevOps context is simple: shrink the time between “something broke” and “someone is working on it”. Mean time to resolve is the sum of detection, response and repair, and detection is the part that is often longest and easiest to improve. A synthetic check every minute or two means a failure is noticed within minutes, regardless of whether anyone is looking at a dashboard.

External checks are black-box by design. They do not know about your pods, queues or replicas; they only know whether a request from the internet gets the right answer in time. That makes them a perfect complement to white-box telemetry: when the external check fails, internal metrics tell you why; when internal metrics are fine but the external check fails, the problem is between you and your users.

Which monitor types DevOps teams use

Different parts of a stack need different checks. Most teams combine several of these:

• HTTP(S) monitoring: status code, response time and optionally body content of websites and health endpoints
• Keyword or API assertions: the response contains an expected string or JSON value
• Port and TCP monitoring: databases, mail servers, SSH or custom services accept connections
• Ping (ICMP): basic reachability of hosts and network devices
• Cron job or heartbeat monitoring: a job reports in; silence means it failed
• SSL certificate and domain expiry monitoring: warnings days or weeks in advance

Spot peaks in your response time

Availability is binary; performance is not. A service that answers in four seconds is technically up and practically broken. Recording response time with every check gives you a cheap, continuous latency series from outside your network, including DNS, TCP and TLS time that application metrics do not see.

Set a threshold that matches the endpoint – a few hundred milliseconds for an API health check, perhaps two seconds for a heavy web page – and alert on transitions rather than every slow sample. Peaks that repeat at the same time every day usually point to batch jobs, backups or traffic patterns; peaks after deploys point to regressions. Trace routes and timing breakdowns, where a tool offers them, help separate network problems from slow origins.

Avoid false positives with confirmation and multi-location checks

Nothing destroys trust in alerting faster than pages for problems that do not exist. A single failed request can be caused by a transient network blip, a packet lost on a congested route or a monitoring node with its own issues. Good monitoring therefore confirms a failure before alerting: a second request after a short delay, ideally from a different location.

Multi-location checks also reveal regional problems – a CDN edge that fails only in one continent, or a routing issue at one provider. If your users are global, check from several regions. If they are mostly in one country, a nearby location with a confirmation retry is often enough, and fewer locations mean fewer false regional alarms.

Integrations and alert routing

Alert channels should match severity. A confirmed outage of a customer-facing service deserves a page through an on-call tool such as PagerDuty, Opsgenie or Splunk On-Call, or at least an SMS or voice call. Warnings – slow responses, a certificate expiring in three weeks – belong in a team chat channel in Slack, Microsoft Teams or Discord, or in email. Webhooks let you push events into your own automation, ticket system or chatops bot.

Whatever the channels, define ownership. Every monitor should map to a team or service owner, so an alert never lands in a shared channel where everybody assumes somebody else is handling it. Recurring notifications – a reminder every 30 minutes while a monitor is still down – help make sure a long outage does not go unnoticed after the first alert is acknowledged and forgotten.

Maintenance windows and custom alerts

Planned work should not page anyone. Maintenance windows suppress alerts for a monitor during a scheduled period, so database migrations or provider maintenance do not train the team to ignore notifications. Keep windows short and specific; a monitor that is permanently in maintenance is a monitor nobody trusts.

Custom alert settings per monitor – different contacts, thresholds and delays – let you treat a marketing site differently from a payment API. A common pattern is to alert after two consecutive failures for critical endpoints and after a longer period for less important ones.

Share access with your team

Monitoring is a team asset. Many services offer roles such as admin, write, read-only and alert-only, so engineers can manage monitors while stakeholders only receive notifications. Incident comments and root-cause notes attached to an outage turn the monitoring history into a lightweight incident log.

If you treat infrastructure as code, look for an API or Terraform provider to define monitors next to the services they watch. Monitors created by hand drift; monitors created in the same pull request as the service stay accurate.

Status pages for internal and external communication

A status page shows current health and incident updates to users or to the rest of the company. Public pages reduce support load during incidents; internal, password-protected pages keep other teams informed without everyone joining the incident channel. Status pages can be driven automatically by monitors, updated manually, or both – automatic for detection, manual for the explanation users actually want to read.

Cloud-based or self-hosted?

External monitoring must run outside the infrastructure it watches; otherwise an outage of your network takes the monitor down with it. Cloud-based services solve that by default and start in minutes, without servers, upgrades or their own monitoring. Self-hosted tools give you full control and can watch internal endpoints, but they need a host in a different failure domain and someone to maintain them.

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
nc -zv db.example.com 5432
dig +short example.com A

Many teams use both: a self-hosted tool for internal services and a hosted service for the public edge.

Check intervals and how alerting works

Intervals are a trade-off between detection time, cost and noise. Thirty seconds to one minute suits critical, customer-facing APIs. Five minutes is a common default for websites. Daily is enough for certificate and domain expiry checks. Keep in mind that confirmation adds time: with a one-minute interval and a confirmation retry, detection typically takes two to three minutes.

The typical flow is always the same: a check fails, it is retried or confirmed from another location, an incident opens and notifications go out, and when checks pass again the incident closes automatically with its duration recorded.

Designing health endpoints worth monitoring

An uptime check is only as meaningful as the URL it requests. A static homepage served from a CDN cache can stay green while the application behind it is broken. A dedicated health endpoint gives the monitor a better signal: it should exercise the critical path – reach the database, read from the cache, confirm that a required downstream service answers – and return a clear status code and a small JSON body.

Keep it cheap and safe. Health endpoints are requested hundreds of times a day, so they must not run heavy queries or write data. Separate liveness (the process runs) from readiness (it can serve real traffic), and expose only the latter to external monitoring. Avoid leaking versions, hostnames or stack traces in the response, because the endpoint is public by definition.

SSL certificates and domains: the predictable outages

Expired certificates and lapsed domains are among the most embarrassing outages, because they are entirely predictable. Automated renewal with ACME clients has made them rarer but not extinct: renewals fail silently when DNS challenges break, when a certificate is pinned to an old load balancer or when the payment card on the registrar account expires. A daily expiry check with warnings 14, 7 and 3 days ahead turns these into routine tickets instead of incidents.

Best practices for DevOps uptime monitoring

Most monitoring problems are not missing features but missing discipline. Review your monitors when you review your services: every new endpoint gets a check, every retired one loses it, and every noisy alert is either fixed or tuned.

• Monitor user journeys and health endpoints, not just the homepage
• Make health endpoints check real dependencies, but keep them cheap
• Confirm failures before paging; alert on state changes, not every sample
• Separate pages from warnings and give every monitor an owner
• Use maintenance windows for planned work and review noisy monitors monthly
• Track uptime and detection time as SLO inputs, not vanity numbers

Where monitordefend fits in a DevOps stack

monitordefend is a hosted service for the website layer: it checks the homepage of each site every five minutes from Germany, confirms outages with a second attempt, records response time with a threshold alert and also watches links, indexing, checkout and file integrity. Alerts are email only. It has no port, ping, cron, API-assertion or multi-location checks, no webhooks and no public API, so pair it with a dedicated infrastructure monitor.

Frequently asked questions

How do multi-location checks work?

When a check fails from one location, the service repeats it from one or more other locations. Only if those also fail is the outage confirmed and alerted. This filters out local network problems and reveals failures that only affect one region.

How often should uptime checks run?

Critical APIs are often checked every 30 to 60 seconds, websites every one to five minutes and certificates or domains once a day. Shorter intervals detect faster but cost more and produce more noise if failures are not confirmed.

How does monitoring and alerting work end to end?

The monitor sends requests on a schedule, compares the result with what it expects, confirms failures with a retry, opens an incident and notifies the configured channels. When checks succeed again, it closes the incident and records the downtime.

How many team members can share access?

That depends on the service and plan. Many tools offer roles from admin to alert-only; others have one login per account and rely on shared inboxes or chat channels for distributing alerts.

Does external monitoring replace APM or metrics?

No. External checks tell you that users are affected; APM, metrics and logs tell you why. Use both, and alert on the external signal for user-facing availability.

Related pages

• API monitoring: keep your APIs reliable
• Port monitoring: watch any port on your server
• Cron job monitoring: catch the run that never happened
• Multi-location monitoring: one monitor, every region covered
• Incident management for monitoring: track, filter and resolve outages
• Website Response Time Monitoring