Website & Uptime Monitoring

Know the moment your site stops responding

The agent watches your servers from the inside - monitors watch them from the outside, the way your users see them. Point a monitor at a URL, port, or hostname and know the moment it stops responding, slows down, or is about to expire.

  • HTTP, TCP, DNS, SSL, and domain-expiry checks
  • Response-time alerts, not just up or down
  • Checked from multiple locations, or from inside your own network
Example monitors
  • https://shop.example.com200 · 182ms
  • api.example.comtimeout · alerting
  • api.example.com:443 SSL41 days left
  • db.internal:5432 TCPopen · 3ms
  • example.com domainexpires 2027-03-14

How it works

Checked on a schedule. Escalated the moment it breaks.

Monitors check your endpoints on a schedule and alert through your escalation chains the moment something breaks.

Monitor types

Five monitor types, one workflow.

Every monitor type shares the same setup: pick a target, set the check interval, choose who gets alerted. No separate tools for uptime, certificates, and domains.

  • HTTP / HTTPS

    Request any URL and verify the status code you expect comes back. Custom methods, headers, and timeouts - and every check records the response time.

  • TCP port

    Confirm anything that speaks TCP is accepting connections - databases, mail servers, message brokers, or your own custom services.

  • DNS

    Resolve a record of any type and check the answer contains the value you expect - so a hijacked or misconfigured zone surfaces as an alert, not a mystery.

  • SSL certificate

    Track days-to-expiry and the issuer for every certificate. Set your own warning threshold and get alerted long before the browser warnings start.

  • Domain expiry

    Watch registration expiry dates along with registrar and nameserver details, so a forgotten renewal never takes your site - and your email - offline.

Certificates and domains get their own deep dive on the domain & SSL expiry monitoring page.

Response time

Slow is the new down.

Every HTTP check records how long the response took, so you get a response-time history for each monitor - and you can alert on it. Set a threshold in milliseconds and find out when your site gets slow, not just when it goes dark. Most outages announce themselves as a slowdown first.

https://shop.example.com threshold 600 ms
Example, last 2 hours Alert raised

Where checks run from

Outside your network, and inside it.

  • Checked from multiple locations

    Checks run from AlertKick's monitoring locations around the world, so you see what your users see - not just what looks fine from one vantage point.

  • Internal services too

    Not everything worth monitoring is on the public internet. Run an AlertKick poller inside your own network and point monitors at internal dashboards, admin panels, and private APIs - results flow into the same dashboard and alerting as everything else.

Alerting

Alerts that reach a human.

Monitor failures go through the same pipeline as every other AlertKick alert. A monitor that fails at 3 AM wakes up one person - the right one.

  1. Grouped and deduplicated. One incident per failure, not a burst of identical alerts.
  2. Delivered where you are. Email, SMS, WhatsApp, or Telegram.
  3. Routed to whoever is on call. Using your on-call rotations.
  4. Escalated until someone responds. Through your escalation chains.

What you get

Included on every plan.

Your servers, watched by tonight.

Install one agent. Get security monitoring, infrastructure alerts, and on-call management - all included with every host.