GlockApps Uptime Monitor: do you really need it?

GlockApps sells an Uptime Monitor add-on and bundles a version of it in the Bulk plan. The marketing page promises 24/7 monitoring of your mail server — which sounds essential, because if the server is down mail doesn't go. When you open the feature and read what it actually measures, the picture changes.

This article is the reality check. It will save you an add-on fee if you're a typical ESP user, and it will show you the four free tools that replace 100% of the monitor's signal for power users.

What GlockApps Uptime Monitor actually measures

Under the hood, the monitor is performing four checks on a schedule, typically every 5–15 minutes:

1. MX record ping. A DNS lookup resolves your domain's MX, and the monitor confirms the hostname responds. This catches MX deletion, DNS propagation issues and truly offline servers.
2. SMTP port probe. A TCP connect attempt on port 25 (and sometimes 587). If the port is closed or firewalled, the check fails.
3. TLS certificate validity. Reads the server's STARTTLS certificate and checks expiry + hostname match. Catches expired certs before they cause real delivery failures.
4. Blacklist re-check loop. The same DNSBL lookups the main product runs, scheduled hourly. Alerts if you appear on Spamhaus, SORBS, Barracuda, etc.

That is the entire feature. No magic, no deep inspection. Four checks on a timer with an alerting pipeline in front.

Who actually needs this

The honest answer: if you send through an ESP (Gmail, SendGrid, Postmark, Mailgun, Brevo, Amazon SES, anything hosted) — you do not. The ESP is already running these checks internally, their SRE team is paged on failures, and their SLA is the product.

You need dedicated uptime monitoring if all of these apply:

• You run your own MTA (Postfix, Haraka, Mailu, Mailcow, Exim) on hardware or a VPS you control.
• You send production-critical mail at a volume where a 15-minute outage is a real incident (transactional OTPs, password resets, invoices).
• You do not already have a generic uptime monitoring setup (UptimeRobot, Better Stack, Pingdom) watching the server.

That is roughly 5% of GlockApps users. For everyone else, the feature is selling you a watchtower on infrastructure somebody else already watches.

Free alternatives that replace every check

UptimeRobot for MX and port probing

Cost: free for 50 monitors, 5-minute interval. Replaces: MX ping + SMTP port probe. UptimeRobot has native TCP port monitoring — point it at mail.example.com:25 and mail.example.com:587 and you have the first two checks covered. Email and Slack alerts included.

Robtex / MXToolbox for blacklist re-checks

Cost: free (rate limited). Replaces: blacklist re-check loop. Both run free APIs that query dozens of DNSBLs in one call. You can script a cron job that hits the API every hour and alerts on any listing. A 20-line shell script replaces this piece of GlockApps entirely.

Certbot for TLS certificate monitoring

Cost: free. Replaces: TLS expiry check. If you use Let's Encrypt, Certbot already renews at day 60 and emails you on failure. If you use a purchased cert, Certbot's certbot certificates command plus a weekly cron job catches expiry two weeks before it lands.

cron + dig for MX sanity

Cost: free. Replaces: MX record presence. A one-line cron that runs dig MX example.com and alerts on empty output catches accidental DNS deletion. Belt-and-braces next to UptimeRobot.

A single shell script that does everything

Here is a cron-ready check that combines MX lookup, SMTP port probe and blacklist scan. Paste it into /usr/local/bin/mx-check.sh, run hourly from cron, and wire the alerts to a Slack webhook or an email:

#!/usr/bin/env bash
# mx-check.sh — free GlockApps Uptime Monitor alternative
# Run: */15 * * * * /usr/local/bin/mx-check.sh

DOMAIN="example.com"
SLACK="https://hooks.slack.com/services/XXX/YYY/ZZZ"
DNSBLS=("zen.spamhaus.org" "bl.spamcop.net" "b.barracudacentral.org")

# 1. MX record presence
MX=$(dig +short MX "$DOMAIN" | head -1 | awk '{print $2}' | sed 's/\.$//')
if [ -z "$MX" ]; then
  curl -s -X POST -H 'Content-type: application/json' \
    --data "{\"text\":\"[mail] no MX for $DOMAIN\"}" "$SLACK"
  exit 1
fi

# 2. SMTP port 25 probe
if ! timeout 5 bash -c ">/dev/tcp/$MX/25" 2>/dev/null; then
  curl -s -X POST --data "{\"text\":\"[mail] port 25 down on $MX\"}" "$SLACK"
fi

# 3. DNSBL scan of the MX IP
IP=$(dig +short A "$MX" | head -1)
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')
for bl in "${DNSBLS[@]}"; do
  HIT=$(dig +short "$REV.$bl")
  if [ -n "$HIT" ]; then
    curl -s -X POST --data "{\"text\":\"[mail] $IP listed on $bl\"}" "$SLACK"
  fi
done

That is it. Thirty lines of bash, zero dependencies beyond dig and curl, feature parity with the GlockApps monitor for a single domain. Multiply the domain loop if you run a few.

When paying makes sense anyway

Three situations where even the scripted version is the wrong tool:

• Regulated industries. A managed vendor with an SLA and an audit trail is a compliance artifact. Shell scripts are not.
• No-ops startups. If nobody on the team can write cron, the script will rot. A paid dashboard that nobody neglects is cheaper than an outage.
• You're already paying for the GlockApps Bulk plan. The monitor is bundled. Use it.

Frequently asked questions