The nice part, if you look after more than a couple of domains: RDAP is plain HTTPS that returns JSON. You can query it with curl, filter it with jq, and turn it into an expiry check that runs from cron. Below is how to run an RDAP lookup from the terminal, read what comes back, make sense of the status values, and set up a small script that warns you before a renewal slips.

One RDAP lookup, nothing new to install

An RDAP server answers at a predictable path: its base URL, then domain/, then the name. For .com that server belongs to Verisign:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq .

If you don't know which server handles a TLD, the public redirector at rdap.org looks it up and sends you there with a 302, so curl -sL https://rdap.org/domain/example.com works for any TLD it knows. ICANN offers the same lookup in a browser at lookup.icann.org.

The full reply is long and mostly notices and links. The parts you care about fit in one jq filter:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  name: .ldhName,
  status,
  events: ([.events[] | {(.eventAction): .eventDate}] | add),
  nameservers: [.nameservers[].ldhName],
  dnssec: .secureDNS.delegationSigned
}'

Where the server address comes from

Hard-coding Verisign works for .com and .net. The proper way to find a server is the IANA bootstrap file at https://data.iana.org/rdap/dns.json, which maps each TLD to its RDAP base URL. It's the same file rdap.org and ICANN's lookup read:

curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("com")) | .[1][0]'

That prints https://rdap.verisign.com/com/v1/. Every gTLD is in the file, plus a growing number of country-code TLDs, but not all of them. When we checked this week, .uk was listed while .de, .io and .co were not. Country-code registries aren't bound by ICANN's contracts, so for those you still use the registry's own WHOIS or web lookup.

Reading the reply

Take the fields in the order you'd check them when something has gone wrong.

events is a list of dated actions. registration is when the name was first created, expiration is the date the registry has on file, and last changed is the most recent update to the domain itself, such as new nameservers, a status change or a renewal. Every date is in UTC. last update of RDAP database only tells you how fresh the answer is.

status uses the same values registrars and registries exchange over EPP, written out in plain words. client transfer prohibited is the transfer lock your registrar sets, the one you toggle in its panel. The server ... versions come from the registry, and only the registry can lift them.

nameservers is the delegation, the servers the TLD sends resolvers to. If this list doesn't match your DNS provider, nothing you edit in that provider's zone will ever be seen. It's the same mismatch that dig +trace exposes, viewed from the registry's side.

secureDNS says whether a DS record is published. delegationSigned: true means resolvers will validate DNSSEC for the zone. If you're moving DNS to a new provider and this says true, sort out the DS record before you switch nameservers, or the domain fails validation the moment the change lands.

entities holds the registrar's name and IANA ID, plus an abuse contact. Registrant details are usually missing or marked as redacted. That's privacy policy at work, not a broken lookup.

Registry answer or registrar answer

For .com and .net the registry holds only part of the record. The rest sits with the registrar, and the registry reply points there with a link of type related:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.links[] | select(.rel == "related") | .href'

example.com is a reserved name held by IANA, so it has no such link, but a normally registered .com returns a URL on its registrar's own RDAP server. Query that one as well when you want the registrar's view.

It matters most around expiry. When a .com reaches its expiration date, the registry renews it automatically for a year, and the registrar then has a grace window of up to 45 days to keep it or delete it. So the registry's date can jump a year ahead even though nobody has paid. If the status list includes auto renew period, don't trust that date. Log in to your registrar account and check that the renewal really went through.

Status values worth a second look

Most domains show some mix of the three client ... prohibited values. That's the normal registrar lock, and it's what you want on a name you aren't moving. These are the ones that mean something is happening:

• client hold or server hold: the domain is pulled from the zone and doesn't resolve at all. Registrars set it for things like an unpaid renewal or a registrant email that was never verified.
• pending transfer: a move to another registrar is in progress. If nobody on your side asked for one, call your registrar today.
• redemption period: the domain was deleted and can still be restored, usually for a much higher fee than a renewal.
• pending delete: redemption is over. The name gets released within days and can't be renewed.
• server ... prohibited on its own: a registry-level lock. It's either a paid registry lock or a name the registry is protecting, which is why example.org carries all three.
• active: no statuses at all. Fine for a moment during a transfer, but on a name you're keeping it means only the auth code stands between the domain and a transfer request.

If you're about to move a domain, unlocking a domain before a transfer covers which of these you can clear yourself.

A small expiry check for cron

Registrars send renewal reminders, but they go to whatever email was on the account when it was opened. A script that reads the registry directly doesn't care about a dead mailbox. This one takes a file with one domain per line, finds each TLD's server in the bootstrap file, and prints the days left. It exits with 1 when anything needs a look, so it slots into cron or a monitoring check.

#!/usr/bin/env bash
# Usage: domain-expiry.sh domains.txt [warn_days]
# Needs curl, jq and GNU date.
list=$1; warn=${2:-30}; rc=0
boot=$(curl -fsS https://data.iana.org/rdap/dns.json) || exit 2

while read -r d; do
  [ -z "$d" ] && continue
  tld=${d##*.}
  base=$(jq -r --arg t "$tld" \
    'first(.services[] | select(.[0] | index($t)) | .[1][0]) // empty' <<<"$boot")
  if [ -z "$base" ]; then
    printf '%-22s no RDAP server for .%s, check by hand\n' "$d" "$tld"; continue
  fi

  json=$(curl -s -w '\n%{http_code}' "${base%/}/domain/$d")
  code=${json##*$'\n'}; json=${json%$'\n'*}
  if [ "$code" != 200 ]; then
    printf '%-22s lookup failed: HTTP %s\n' "$d" "$code"; rc=1; continue
  fi

  exp=$(jq -r 'first(.events[] | select(.eventAction=="expiration") | .eventDate) // empty' <<<"$json")
  flags=$(jq -r '[.status[] | select(test("hold|redemption|pending delete|auto renew period"))] | join(", ")' <<<"$json")
  if [ -z "$exp" ]; then
    printf '%-22s no expiration date in the RDAP reply\n' "$d"; rc=1; continue
  fi
  days=$(( ($(date -d "$exp" +%s) - $(date +%s)) / 86400 ))

  note=ok
  [ "$days" -lt "$warn" ] && { note="RENEW SOON"; rc=1; }
  [ -n "$flags" ] && { note="CHECK: $flags"; rc=1; }
  printf '%-22s expires %s  %4d days  %s\n' "$d" "${exp%%T*}" "$days" "$note"
  sleep 1
done < "$list"
exit $rc

A few notes on what it does and why:

• It sleeps a second between lookups. Registries rate-limit RDAP, and a burst of queries can earn you HTTP 429 replies instead of data.
• A 404 means the registry has no such name. In a list of domains you own, that's either a typo or a domain that's already gone. If it's gone, run a domain search right away to see whether you can register it again.
• TLDs missing from the bootstrap file get reported, not skipped silently, so a .de name doesn't fall off your radar.
• It uses GNU date -d. On macOS, install coreutils and swap in gdate.

To run it every Monday and only hear about problems, wrap it in chronic from the moreutils package, which stays quiet unless the command exits with an error:

MAILTO=ops@example.com
0 8 * * 1  chronic /usr/local/bin/domain-expiry.sh /etc/domains.txt 45

A 45-day threshold leaves room to fix a declined card or a dead login before anything breaks. Want to see the warning fire once? Pass a big number, such as 300, like the second run in the screenshot.

What RDAP can't tell you

RDAP shows what the registry knows. It can't tell you whether the card on file still works, whether auto-renew is switched on, or who at your company holds the registrar login. Those live in the registrar account, and they're covered in renewing a domain name before it expires. Keep the script running next to that checklist, not instead of it.

If the audit turns up names scattered across old registrar accounts, you can bring them under one login with a domain transfer to Pro Gineous, and every lookup above works the same afterwards.

Related reading

• Unlocking a Domain Before a Transfer
• Renewing a Domain Name Before It Expires
• What to Check After a Domain Transfer
• How to Read dig Output When DNS Looks Wrong

Originally published on the Pro Gineous blog.

The cause is almost always WP-Cron, the scheduler built into WordPress. It makes one big assumption about your traffic, and when that assumption fails, scheduled posts, backups and digest emails all slip together. Here's how it works, how to confirm it's the culprit, and how to replace it with something that runs on time.

WP-Cron isn't a clock

When you click Schedule, WordPress doesn't set a timer anywhere. It saves the post with the status future and adds a one-off job called publish_future_post to a list stored in the database (the cron option in wp_options). Plugin chores like backups and update checks live in the same list.

Nothing watches that list on its own. Instead, on each page request WordPress checks whether anything on it is due. If something is, it fires a quick HTTP request at its own wp-cron.php (a loopback request) and carries on without waiting for the reply. That second request is what actually publishes your post.

So the default setup needs three things to line up: a visit that reaches PHP, a loopback request that gets through, and a server that lets the job finish. Take away any one of them and the schedule drifts.

Why the schedule slips

Nobody visited. A small site can go hours without one uncached request. The post is due at 11:00, the first real visit comes at 12:40, and that's when it goes live. Posts on a quiet site appearing late by a random amount is the classic pattern.

The visits never reached WordPress. Full-page caching (a caching plugin's static files, a server-level cache, or a CDN in front of the site) is great for speed, but a cached page is served without loading WordPress, so nothing checks the job list. A busy site behind a good cache can behave exactly like a site with no visitors.

The loopback request fails. The server has to be able to reach its own domain over HTTP. A staging password (HTTP basic auth) answers 401. A security plugin or firewall rule may block wp-cron.php. After a migration, the server can still resolve your domain to the old IP (DNS answers are cached, as covered in how long DNS changes take to show up) and send the request to a machine that no longer hosts the site. WordPress flags this in Tools > Site Health as "Your site could not complete a loopback request."

Cron was switched off and never replaced. Someone added define( 'DISABLE_WP_CRON', true ); to wp-config.php to stop cron running on page loads, which is a sensible thing to do, but the server cron job that's meant to take over was never created. Or it existed on the old server and didn't come along in the move, because it lives in the server's crontab, not in WordPress.

A heavy job ran out of time. Cron jobs run in a normal PHP request, so they're bound by the same time limit. A big backup or import that hits that limit gets killed mid-run, and whatever was queued after it waits for the next spawn.

Also rule out the time zone under Settings > General. If it's set to UTC while you think in local time, every post goes out "late" by the same few hours. That's a settings problem, not a scheduler one.

Ask WordPress what it thinks is due

If your hosting gives you SSH, WP-CLI answers this in three commands. Run them from the site's folder (often public_html):

wp post list --post_status=future --fields=ID,post_title,post_date
wp cron event list
wp cron test

The first command lists posts still waiting to publish, with the time they were due in the site's own time zone. In wp cron event list, the next_run_gmt column is in UTC, so on a site set to Cairo time (UTC+3) the 08:00:00 job is the 11:00 post. Any row whose next_run_relative says now is overdue: WordPress knows the job should run and nothing has run it. One overdue row could be bad luck. A column full of now, including core jobs like wp_version_check, means cron hasn't run for hours.

wp cron test makes the same loopback request WordPress would, but waits up to three seconds for the answer. Here's how to read the result:

• Success: WP-Cron spawning is working as expected. The loopback path is fine, so look at traffic and caching instead.

• cURL error 28 (a timeout, as in the screenshot) usually points at a firewall rule, a DNS answer pointing somewhere else, or a server that can't reach itself.

• HTTP status code: 401 means a password sits in front of the site.

• An error saying the DISABLE_WP_CRON constant is set means cron is switched off on purpose, so go and find the server cron job that should exist.

No SSH? The free WP Crontrol plugin shows the same event list inside wp-admin, and Site Health reports late scheduled events and failed loopback requests.

Hand the schedule to the server

The reliable fix is to stop depending on visits at all. Let the server's own scheduler run the queue every few minutes, and tell WordPress to stop trying on page loads.

Start by switching off the visit-triggered runner:

wp config set DISABLE_WP_CRON true --raw

That writes define( 'DISABLE_WP_CRON', true ); into wp-config.php. You can also add the line by hand, anywhere above the /* That's all, stop editing! */ comment.

Next, add a server cron job. Cron runs with a very short PATH, so find the full path to WP-CLI with which wp and use it in the line. With WP-CLI available, this is the cleanest version, because it runs due events directly in PHP instead of going through HTTP:

*/5 * * * * cd /home/exampleco/public_html && /usr/local/bin/wp cron event run --due-now --quiet

Without WP-CLI, request wp-cron.php over HTTP instead:

*/5 * * * * curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron"

The HTTP version still depends on the server reaching itself, so if wp cron test failed earlier, fix that first or stick with WP-CLI. Over SSH, add the line with crontab -e. On cPanel hosting, the Cron Jobs page takes the same command and has a ready-made "Once Per Five Minutes" option. Five minutes is a good default: scheduled posts go out within a few minutes of their time, and the server barely notices.

Finally, clear the backlog once by hand with wp cron event run --due-now, then check the stuck post with wp post get 1482 --field=post_status. It should now say publish.

If you really can't add a cron job

Some plans offer neither cron nor SSH. One fallback is an external cron service that requests https://example.com/wp-cron.php?doing_wp_cron every few minutes, which works as long as that URL isn't blocked or cached. The other is define( 'ALTERNATE_WP_CRON', true );, which makes WordPress run cron by redirecting a visitor's own request instead of making a loopback call. It sidesteps a broken loopback but still needs visits, and visitors may see ?doing_wp_cron= in the address bar. Treat both as stopgaps.

Prove it the next day

The day after the change, check that it actually works:

• Schedule a test post ten minutes out and stay off the site. If it goes live on time with no visits from you, the server cron is doing the work. (If new posts are shared to social media automatically, pause that first, then trash the test post.)

• Run wp cron event list again. Recurring jobs like wp_version_check should show a future time, not now.

• Add the cron line to your migration notes. The next time the site moves hosts, it's the one setting that won't move with the files and database, and if both old and new servers keep running cron against the same site during a cutover, scheduled emails can go out twice.

WP-Cron is a reasonable default for a site that gets steady, uncached traffic. For anything that publishes on a schedule or runs nightly backups, a five-minute server cron job is the boring, dependable choice. Pro Gineous shared hosting plans include cPanel, SSH and WP-CLI, so everything above can be set up from the control panel or the terminal in a few minutes.

Related reading

• Speeding Up WordPress Without More Plugins

• How to Move a WordPress Site to a New Host

• How to Fix a WordPress Error Without Making It Worse

Originally published on the Pro Gineous blog.

This is where the dig command earns its place. A browser hides DNS behind layers of caching; dig asks one specific server one specific question and prints exactly what came back. Once you can read that output, "DNS is broken" turns into a short list of facts: who answered, what they said, and how long they will keep saying it.

dig ships with macOS and most Linux distributions (on Debian and Ubuntu, install dnsutils). The examples use example.com; in our scenario the old server is 203.0.113.10 and the new one is 203.0.113.20.

Start with one plain query

dig example.com

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48211
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            2917    IN      A       203.0.113.10

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sat Oct 17 10:42:18 EEST 2026
;; MSG SIZE  rcvd: 56

The screenshot adds a second query for a name that doesn't exist, so you can see NXDOMAIN next to a normal answer.

It looks noisy, but it's only a few blocks.

The header: status and flags

The ->>HEADER<<- line holds the most important word in the output: status. Check it before looking at any IP. NOERROR means the server answered without a problem, not that the answer is the one you wanted.

The flags line tells you what kind of server you were talking to:

• qr: this is a response. Always there.

• rd: you asked for recursion. dig does this by default.

• ra: the server offers recursion, so you're talking to a resolver, not the source of the record.

• aa: authoritative answer. The server holds the zone itself. You only see this when you query the domain's own nameservers.

QUESTION and ANSWER

QUESTION echoes what you asked: name, class IN, type A. A typo or a forgotten MX shows up here.

ANSWER holds the records in five columns: name, TTL, class, type, value. Here the resolver says example.com points to 203.0.113.10, the old server.

TTL is a countdown

The second column is the TTL in seconds. On a resolver it's the time left before that cached copy expires, not the number you typed into your DNS panel. Run the query twice and you'll watch it drop. Above, 2917 seconds remain, so this resolver will hand out the old IP for roughly another 48 minutes, whatever you change in the meantime. On the authoritative server, the TTL is always the full configured value.

AUTHORITY, ADDITIONAL and the footer

AUTHORITY mostly shows up when there's no answer. On an NXDOMAIN or an empty response you'll find the zone's SOA record there, and its last number caps how long the "doesn't exist" result gets cached. When you query a TLD server, AUTHORITY is where the delegation (the NS records) lives. ADDITIONAL carries helpers such as nameserver IPs.

In the footer, the SERVER line matters. 127.0.0.53 is systemd-resolved on your own machine, which means you're looking at your local cache, not at the internet.

What the status codes are telling you

On SERVFAIL, retry with +cd (checking disabled). If an answer appears, DNSSEC validation is failing, often because a domain moved to new nameservers while an old DS record still sits at the registrar. And REFUSED from a nameserver you expected to be authoritative usually means the zone was never created, or never activated, on that provider.

Ask a specific resolver, then ask the source

By default dig uses your system's resolver. Point it elsewhere with @:

dig example.com @1.1.1.1
dig example.com @8.8.8.8

Public resolvers are still caches. To see what the zone really says, find its authoritative nameservers and query one directly:

dig +short NS example.com
dig example.com @ns1.example.net +norecurse

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com @ns1.example.net +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61027
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       203.0.113.10

+short strips everything except the values. In the authoritative reply, look for the aa flag and the full TTL. If the authoritative server already returns the new IP and a resolver still returns the old one, nothing is broken; you're waiting for cached copies to expire. If the authoritative server returns the old IP, like the one above, your change never reached the zone that's actually live. That leads to the next check.

Follow the chain with +trace

dig +trace +nodnssec example.com

+trace skips your resolver's cache and walks the delegation itself. It asks a root server who handles .com, asks a .com server who handles example.com, then asks that nameserver for the record. The +nodnssec part just hides the signature records so the output stays readable.

Here are the last two hops, trimmed:

example.com.            172800  IN      NS      ns1.example.net.
example.com.            172800  IN      NS      ns2.example.net.
;; Received 87 bytes from 192.5.6.30#53(a.gtld-servers.net) in 24 ms

example.com.            3600    IN      A       203.0.113.10
;; Received 56 bytes from 198.51.100.53#53(ns1.example.net) in 31 ms

Each Received ... from line names the server that sent the block above it. The hop from a.gtld-servers.net is the delegation your registrar published. The final hop is what the zone itself says.

When the registrar and the zone disagree

This is the classic "I changed the record and nothing happened." You moved DNS to a new provider and created the records there, but the registrar still delegates to the old nameservers. The new zone is perfect, and nobody is reading it.

Ask a .com TLD server directly what the delegation looks like:

dig NS example.com @a.gtld-servers.net

The NS records come back in the AUTHORITY section, not ANSWER, because the TLD server is referring you elsewhere rather than answering itself. That's also why +short prints nothing here. Then compare with the zone you've been editing and a public resolver:

dig +short NS example.com @ns1.example.org
dig +short example.com @ns1.example.org
dig +short example.com @1.1.1.1

Here the TLD still points to ns1.example.net and ns2.example.net, while the new provider's zone lists ns1.example.org and already holds the new IP. Resolvers follow the delegation, so they keep reading the old zone. The fix lives at the registrar: update the nameservers there, and remove any stale DS record if DNSSEC was enabled. Delegation records at the TLD usually carry a 172800-second TTL (two days), so resolvers that cached the old NS set can take a while to catch up.

Quick checks for MX, TXT and CNAME

Add the record type, and +short makes each check one line:

$ dig +short MX example.com
10 mail.example.com.
20 mail2.example.com.
$ dig +short TXT example.com
"v=spf1 ip4:198.51.100.25 include:_spf.example.net -all"
$ dig +noall +answer www.example.com
www.example.com.        3600    IN      CNAME   example.com.
example.com.            2917    IN      A       203.0.113.10

Worth checking while you're there:

• MX records must point to hostnames, never to IP addresses or CNAMEs. The lower number has priority.

• A domain should publish exactly one v=spf1 TXT record. Two of them is an error, and receivers treat it as an SPF failure.

• DKIM and DMARC live on their own names: dig +short TXT selector1._domainkey.example.com and dig +short TXT _dmarc.example.com.

• +noall +answer shows a whole CNAME chain in one go. A name that has a CNAME can't hold any other records, which is why the bare domain usually can't be a CNAME.

Clear the cache on your own machine

Once the authoritative servers and public resolvers agree, your own computer may still hold the old answer.

On Linux with systemd-resolved:

sudo resolvectl flush-caches
resolvectl statistics    # "Current Cache Size" drops to 0

On macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Windows it's ipconfig /flushdns. Browsers keep their own DNS cache, so restart the browser too. Public resolvers can't be flushed from your machine, though the big public DNS services offer a purge page for single names.

A short troubleshooting checklist

1. Run dig name type and read status before anything else.

2. Check the SERVER line so you know whose cache you're looking at.

3. Find the nameservers with dig NS, query one with @, and look for the aa flag.

4. Compare that with the TLD delegation (dig NS name @a.gtld-servers.net or +trace). They must match.

5. Ask @1.1.1.1 and @8.8.8.8 and note the remaining TTL. That's how long you'll wait.

6. On SERVFAIL, retry with +cd to rule DNSSEC in or out.

7. Flush local caches only after the authoritative answer is correct.

Most DNS problems aren't mysterious. They're a mismatch between two layers (registrar and zone, zone and cache, cache and browser), and the dig command shows you exactly which two. If your domains and DNS are managed at Pro Gineous, our support team is happy to walk through these checks with you whenever something looks off.

Every domain registered through our domain search and registration page comes with DNS you can manage yourself, so you can check your records with dig as you change them.

Related reading

• How Long Do DNS Changes Take to Show Up?

• What an A Record Does in DNS

• Setting Up DNS Records for Your Website and Mail

Originally published on the Pro Gineous blog.

Assumptions: you can SSH in as root (or with sudo), you have a second terminal ready, and you are okay restarting SSH carefully.

Minutes 0-3: update and create a user

apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy

Use a real password for deploy even if you plan to disable password SSH later. Keep the root session open until key login works.

Minutes 3-6: SSH keys only

On your laptop:

ssh-copy-id deploy@YOUR_SERVER_IP

Confirm you can open a second SSH session as deploy before you change sshd. Then edit /etc/ssh/sshd_config (or a drop-in under /etc/ssh/sshd_config.d/):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Reload SSH (name varies by release):

sudo systemctl reload ssh || sudo systemctl reload sshd

If the second session still works, you are safe. Only then close the root session.

Minutes 6-8: firewall

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

If you use a non-default SSH port, allow that port instead of OpenSSH.

Minutes 8-10: fail2ban

apt install -y fail2ban
systemctl enable --now fail2ban

Default jails already watch SSH on many Ubuntu images. Check:

fail2ban-client status
fail2ban-client status sshd

If sshd is missing, add a simple jail under /etc/fail2ban/jail.d/sshd.local:

[sshd]
enabled = true

Then systemctl restart fail2ban.

Minutes 10-12: automatic security updates

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Confirm it is active:

systemctl status unattended-upgrades --no-pager

Minutes 12-14: timezone, swap, noise

timedatectl set-timezone UTC   # or your region
ss -tulpn

Close ports and services you do not need. On a 1-2 GB box with no swap:

fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Skip swap if your provider already gives you enough RAM or managed swap.

Minutes 14-15: snapshot and backups

1. Take a provider snapshot now, while the box is clean and hardened.

2. Schedule off-server backups for anything that will hold real data (database dumps, /var/www, secrets). A snapshot is not a tested restore.

3. Write down where backups live and how you would restore them.

What this does not cover

• Application security (WordPress plugins, dependency CVEs, auth bugs)

• Secrets management (API keys in git, world-readable .env files)

• Monitoring and alerting

• DDoS or network-layer attacks beyond a basic firewall

Those are next layers. This checklist only makes a fresh VPS less of an open door.

Closing

Own the server, own the failure modes. Fifteen minutes of boring hygiene beats a weekend of incident cleanup.

If you need a server to practice on, Pro Gineous VPS plans start at $6.99/mo. Whatever provider you pick, own your domain, keep SSH locked down, and test a restore at least once.