If you’re managing a production website, high availability isn’t a luxury — it’s a necessity. Imagine this: your primary server unexpectedly goes down. With no standby, your users are met with an error page and your brand takes a hit.

Now, imagine a better scenario — within seconds, traffic reroutes to a standby server, preserving uptime while you fix the issue. That’s the magic of Cloudflare Load Balancing. In this post, I’ll show you how to configure failover for your apex domain (e.g., example.com) using two backend servers: one live and one on standby.

---

The Goal

• Primary server = serves live data.
• Standby server = backup, possibly with older data.
• Only use standby if primary fails.
• Works even at the apex domain (thanks to Cloudflare Load Balancer).

---

Step-by-Step Configuration

1. Prep Your Infrastructure

Make sure both servers:

• Are accessible via public IP or resolvable hostname.
• Respond on a simple endpoint (like /health) that can be used for uptime checks.

2. Log In to Cloudflare

• Go to the domain you want to configure.
• Navigate to the “Traffic” section.
• Open Load Balancing (note: it’s a paid add-on).

3. Set Up Your Load Balancer

Click “Create Load Balancer” and configure:

• Hostname: Leave this blank for apex (example.com).
• TTL: Use a low TTL (e.g., 30 seconds) for fast response to failures.

4. Create Pools

Pools define which servers serve traffic.

Pool 1: Primary

• Name: Primary-Pool
• Add your live server.
• Configure a health check (e.g., https://yourdomain.com/health, status code 200).

Pool 2: Standby

• Name: Standby-Pool
• Add the backup server.
• Use the same health check logic.

5. Define Failover Order

• Drag Primary-Pool to the top.
• Enable Failover mode.
• Optionally disable session affinity (unless sticky sessions are needed).

6. Point DNS to Load Balancer

• Go to the DNS tab for your domain.
• Make sure your @ record is an A or CNAME pointing to the load balancer.
• Keep orange cloud enabled for proxying and failover.

---

Testing the Setup

Bring your primary server offline or simulate a failed health check:

• You should see traffic shift to the standby within seconds.
• Restore the primary — traffic will return automatically once it’s healthy.

---

Pro Tip

Want a smarter health check than just HTTP 200? Write a custom /health route that tests:

• Database connectivity
• Disk space
• App responsiveness
• Anything critical to your service’s integrity

# Get the latest version number
MINISERVE_VERSION=$(curl -s https://api.github.com/repos/svenstaro/miniserve/releases/latest | grep -Po '"tag_name": "v\K[0-9.]+')

# Download the binary
curl -L -o miniserve "https://github.com/svenstaro/miniserve/releases/latest/download/miniserve-${MINISERVE_VERSION}-x86_64-unknown-linux-musl"

# Make it executable
chmod +x miniserve

# Move it to a directory in your PATH (optional)
sudo mv miniserve /usr/local/bin/

# Run it (serving current directory)
miniserve .

.

#!/bin/bash

# Set the directory to the first argument, default to current dir if not provided
DIR="${1:-.}"

# List files with size, last modified, and MD5 hash, sorted by modified time (newest first)
find "$DIR" -type f -printf "%T@ %p\n" | sort -nr | while read -r line; do
    timestamp=${line%% *}
    filepath=${line#* }
    mod_time=$(date -d "@$timestamp" "+%Y-%m-%d %H:%M:%S")
    size=$(stat --printf="%s" "$filepath")
    hash=$(md5sum "$filepath" | awk '{print $1}')
    printf "%-10s  %-20s  %-40s  %s\n" "$size" "$mod_time" "$hash" "$filepath"
done

# Serve the directory using miniserve on port 8000
miniserve "$DIR" --port 8000

When managing a server or workstation, unexpected CPU spikes can slow down the system, degrade performance, or even lead to crashes. A proactive solution is to automate system restarts when the CPU usage exceeds a threshold. Instead of relying on inefficient while loops, we’ll leverage the systemd service and timer mechanism for optimized event-based execution.

Why Use systemd Instead of Polling?

Most traditional monitoring scripts rely on a while loop that constantly checks CPU usage, consuming resources unnecessarily. With systemd, we:

• Avoid inefficient polling.
• Ensure scheduled execution without constant CPU usage.
• Easily control activation intervals using timers.

---

Step 1: Creating the CPU Monitoring Script

We will write a Bash script to check CPU usage and trigger a restart if it surpasses a set threshold.

1. Write the Script

Open a terminal and create the script file:

sudo nano /usr/local/bin/cpu_monitor.sh

Add the following content:

#!/bin/bash

THRESHOLD=90  # Define CPU usage limit
CPU_USAGE=$(grep 'cpu ' /proc/stat | awk '{usage=($2+$4)*100/($2+$4+$5)} END {print int(usage)}')

if [ "$CPU_USAGE" -ge "$THRESHOLD" ]; then
    echo "High CPU detected ($CPU_USAGE%), rebooting system..."
    sudo reboot
fi

2. Make the Script Executable

sudo chmod +x /usr/local/bin/cpu_monitor.sh

This script:
Extracts CPU usage directly from /proc/stat without external dependencies.
Uses integer-based comparison to eliminate the need for bc.
Triggers a reboot if CPU usage exceeds the predefined threshold.

---

Step 2: Setting Up a systemd Service

Next, we create a systemd service to execute this script.

1. Create a New Service File

sudo nano /etc/systemd/system/cpu-monitor.service

Add the following content:

[Unit]
Description=Monitor CPU usage and restart if overloaded
After=network.target

[Service]
ExecStart=/usr/local/bin/cpu_monitor.sh
Type=simple

[Install]
WantedBy=multi-user.target

2. Reload Systemd and Enable the Service

sudo systemctl daemon-reload
sudo systemctl enable cpu-monitor.service

At this point, we have created a service that can manually run our script.

---

Step 3: Scheduling the Script with a systemd Timer

Instead of manually running the service, we configure a timer for automated execution.

1. Create a Timer File

sudo nano /etc/systemd/system/cpu-monitor.timer

Add the following content:

[Unit]
Description=Run CPU monitor every 10 seconds

[Timer]
OnUnitActiveSec=10s
Unit=cpu-monitor.service
Persistent=true

[Install]
WantedBy=timers.target

This ensures:
The service runs every 10 minutes.
It activates only when necessary instead of constant polling.

2. Enable and Start the Timer

sudo systemctl enable cpu-monitor.timer
sudo systemctl start cpu-monitor.timer

3. Verify the Timer

To ensure the timer is functioning:

systemctl list-timers --all | grep cpu-monitor

To manually trigger the service:

sudo systemctl start cpu-monitor.service

To check logs for execution status:

journalctl -u cpu-monitor.service --no-pager

---

Step 4: Fine-Tuning for Stability

Before deploying this setup on a production server, consider:
Logging CPU spikes before rebooting for debugging.
Triggering alerts instead of an immediate reboot (via email or notifications).
Including RAM and Disk usage checks for more robust monitoring.

Using systemd, we have built an efficient and event-driven solution to restart a system under high CPU load. Unlike polling loops, this method preserves resources and runs only when needed.

A Bash script that archives a specified directory and securely uploads it to an S3 bucket is described.

Overview

The script is designed to:

• Resolve the supplied directory to its canonical absolute path.
• Create a compressed archive using tar and generate a safe, filename-friendly archive name.
• Construct an S3 object key based on the target directory.
• Securely sign and transfer the archive to the specified S3 endpoint using curl.
• Clean up local artifacts after a successful upload.

Our implementation leverages practices such as error propagation (set -euo pipefail), clear function abstractions, detailed debug logging (when enabled), and credential placeholders to emphasize security.

Best Practices Applied

1. Robust Error Handling:
   The script is configured with set -euo pipefail to ensure that errors are quickly surfaced and that command pipelines are robust.
2. Canonical Path Resolution:
   Instead of relying solely on the current working directory, we convert the input to a canonical absolute path using realpath (or an equivalent fallback). This guarantees consistent outcomes regardless of how the input path is specified.
3. Secure Credential Management:
   While the script uses placeholders for the S3 credentials and endpoint details, the design encourages the usage of secure storage solutions (e.g., environment variables or Azure Key Vault) in a production setting.
4. Modular Design:
   The script is broken into well-defined functions (for debugging, path resolution, archiving, uploading, and cleanup), which enhances readability and maintainability.
5. Clean Output for Integration:
   Debug and progress information is sent to standard error (stderr) to avoid interfering with standard output. This makes the script suitable for integration with other automated processes.

Complete Script

The following script encapsulates these design principles. Replace the placeholder values <YOUR_S3_KEY>, <YOUR_S3_SECRET>, <YOUR_S3_HOST>, and <YOUR_S3_BUCKET> with your actual credentials and configuration.

#!/bin/bash
set -euo pipefail

# Set DEBUG=1 to enable detailed debug output; 0 disables debug messages.
DEBUG=1

# Timestamp for naming (e.g. 20250424-1804)
now="$(date +'%Y%m%d-%H%M')"

# AWS S3 Credentials – replace these with your actual credentials.
s3Key="<YOUR_S3_KEY>"
s3Secret="<YOUR_S3_SECRET>"

# S3 Configuration – replace placeholders with your S3 host and bucket name.
host="<YOUR_S3_HOST>"        # e.g., s3.amazonaws.com or your designated endpoint.
bucket="<YOUR_S3_BUCKET>"      # e.g., my-backup-bucket.
contentType="application/x-tar"

#-----------------------------------------------------
# Function: debug
#-----------------------------------------------------
# Outputs debugging information to stderr.
debug() {
    if [[ ${DEBUG:-0} -eq 1 ]]; then
        echo "[DEBUG]" "$@" >&2
    fi
}

#-----------------------------------------------------
# Function: resolve_path
#-----------------------------------------------------
# Resolves the supplied path to its canonical absolute path.
resolve_path() {
    local input="$1"
    if command -v realpath >/dev/null 2>&1; then
        realpath "$input"
    elif command -v readlink >/dev/null 2>&1 && readlink -f "$input" >/dev/null 2>&1; then
        readlink -f "$input"
    else
        # Fallback: use pwd with parameter expansion.
        echo "$(cd "$(dirname "$input")" && pwd)/$(basename "$input")"
    fi
}

#-----------------------------------------------------
# Function: create_archive
#-----------------------------------------------------
# Archives the provided directory into a tar.gz file and saves it in /tmp.
# The archive filename is derived from the canonical directory path,
# replacing '/' with '-' to produce a safe filename.
create_archive() {
    local dir="$1"
    # Convert the directory path to its absolute canonical form.
    local abs_dir
    abs_dir=$(resolve_path "$dir")
    debug "Absolute path for directory: $abs_dir"

    # Generate a safe directory name for the archive (replace '/' with '-').
    local safe_dir
    safe_dir=$(echo "$abs_dir" | sed 's#/#-#g')
    debug "Safe directory name: $safe_dir"

    local filename="/tmp/grrg-${safe_dir}-${now}.tar.gz"
    debug "Creating archive: $filename from directory: $abs_dir"

    # Use tar with the -C flag so only the directory’s basename is stored in the archive.
    tar -czf "$filename" -C "$(dirname "$abs_dir")" "$(basename "$abs_dir")"
    debug "Archive created at: $filename"

    if [[ -f "$filename" ]]; then
        debug "Archive file details:" 
        ls -l "$filename" >&2
    else
        echo "Error: Archive $filename not created." >&2
        exit 1
    fi
    echo "$filename"
}

#-----------------------------------------------------
# Function: upload_to_s3
#-----------------------------------------------------
# Uploads the created archive file to S3 using curl.
# Constructs the S3 object key from the target directory’s last folder name
# and the archive’s basename.
upload_to_s3() {
    local filename="$1"
    local target_dir="$2"

    # Validate that the archive file exists.
    if [[ ! -f "$filename" ]]; then
        echo "Error: Archive file '$filename' does not exist." >&2
        exit 1
    fi

    local archive_basename
    archive_basename=$(basename "$filename")
    local target_folder
    target_folder=$(basename "$target_dir")
    # S3 object key format: <target_folder>/<archive_basename>
    local s3_file="${target_folder}/${archive_basename}"

    local resource="/${bucket}/${s3_file}"
    local dateValue
    dateValue=$(date -R)
    local stringToSign="PUT\n\n${contentType}\n${dateValue}\n${resource}"
    local signature
    signature=$(echo -en "$stringToSign" | openssl sha1 -hmac "$s3Secret" -binary | base64)

    debug "S3 Upload Info:"
    debug "Archive filename: $filename"
    debug "S3 Resource: $resource"
    debug "Date: $dateValue"
    debug "StringToSign:" 
    debug "$stringToSign"
    debug "Signature: $signature"

    echo "Uploading $filename to S3..." >&2
    curl --progress-bar -# -k -L -X PUT -T "$filename" \
         -H "Host: ${bucket}.${host}" \
         -H "Date: ${dateValue}" \
         -H "Content-Type: ${contentType}" \
         -H "Authorization: AWS ${s3Key}:${signature}" \
         "https://${bucket}.${host}/${s3_file}" || {
             echo "Error during file upload." >&2
             exit 1
         }
    echo "Uploaded successfully!" >&2
}

#-----------------------------------------------------
# Function: cleanup
#-----------------------------------------------------
# Removes the local archive file after successful upload.
cleanup() {
    local filename="$1"
    echo "Removing local archive: $filename" >&2
    rm -f "$filename"
    debug "Local archive removed."
}

#-----------------------------------------------------
# Main Execution
#-----------------------------------------------------
if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <directory>" >&2
    exit 1
fi

input_dir="$1"
abs_input_dir=$(resolve_path "$input_dir")
if [[ ! -d "$abs_input_dir" ]]; then
    echo "Error: '$abs_input_dir' is not a valid directory." >&2
    exit 1
fi

debug "Starting backup for directory: $abs_input_dir"

archive_file=$(create_archive "$abs_input_dir")
upload_to_s3 "$archive_file" "$abs_input_dir"
cleanup "$archive_file"

echo "Backup and upload process completed!" >&2

How to Deploy and Use

1. Installation:
   Save the script as /usr/local/bin/backup_to_s3, and then make it executable with the following command:

   sudo chmod +x /usr/local/bin/backup_to_s3

2. Configuration:
   Replace the placeholders in the script with your actual S3 credentials and configuration values. Ideally, store secrets securely and avoid hardcoding them in the source file.
3. Execution:
   Run the script by specifying a single directory. The script accepts both relative and absolute paths (converting relative paths to canonical absolute paths using realpath or a fallback). For example:

   sudo backup_to_s3 /path/to/your/directory

or

   cd /path/to/your
   sudo backup_to_s3 directory

Conclusion

The script is suitable for production environments where reliability is critical.

If you have any questions or improvements, please leave a comment or get in touch. We hope this solution enhances your backup strategy and provides a foundation for further automation.

Inspired from simple-psr-4-autoloader .

Have you ever used a composer.json file purely for the need of registering a PSR-4 autoloader? I have, and it always felt a little weird to require such a hunk of code for such a simple task. It adds a vendor folder and a bunch of empty files. I don’t like that overhead when it’s not necessary.

It’s also not ment to replace Composer in any way, because that is way more optimized. It’s just that for a simple plugin or theme you don’t need the overhead Composer creates.

<?php
spl_autoload_register(function (string $class_name): void {
    $namespace = 'MyProject';
    if (strpos($class_name, $namespace) === 0) {
        $class_file = './src';
        $class_file .=
            str_replace(
                [$namespace, '\\'],
                ['', DIRECTORY_SEPARATOR],
                $class_name)
                . '.php';
        if (file_exists($class_file)) {
            require_once $class_file;
            return;
        }
    }
});

Add this code to autoload.php and include it in index.php (or any other entrypoint you may have).

First you may create a new command uisng vim /usr/local/bin/log-usage and chmod +x to make it executable.

#!/bin/bash

# Function to get network upload and download
get_network_data() {
    # Adjust the following lines to match your system/network interface
    network_data=$(cat /proc/net/dev | grep eth0 | awk '{print $2, $10}')
    network_upload=$(echo $network_data | awk '{print $1}')
    network_download=$(echo $network_data | awk '{print $2}')
}

# Function to get percentage of disk usage
get_disk_usage() {
    disk_usage=$(df -h / | awk 'NR==2 {print $5}')
}

# Function to get CPU percentage
get_cpu_percentage() {
    cpu_percentage=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}')
}

# Function to get RAM percentage
get_ram_percentage() {
    ram_percentage=$(free | grep Mem | awk '{print $3/$2 * 100.0}')
}

# Function to get current date and time
get_datetime() {
    datetime=$(date +"%Y-%m-%d %H:%M:%S")
}

# Fetch all metrics
get_network_data
get_disk_usage
get_cpu_percentage
get_ram_percentage
get_datetime

# Display the data
echo "$datetime, upload $network_upload KB, download $network_download KB, disk $disk_usage, cpu $cpu_percentage %, ram $ram_percentage %"

Then, you can register a cronjob (using crontab -e or vim /etc/cron.d/usage) to periodically run it.

Google Search Console (GSC) is the secret weapon in your SEO arsenal—versatile, powerful, and sometimes underutilized. If you’re aiming to conquer the search rankings, understanding GSC is mission-critical. Here’s a tactical breakdown of its main menus and submenus, infused with a touch of humor to keep things engaging.

---

1. Dashboard

• Overview: Your command center upon logging in. It provides a snapshot of your site’s performance metrics—clicks, impressions, and any lurking issues. Think of it as the morning briefing before you head into battle.

---

2. Performance

• Search Results: Automatically enabled, this is where the rubber meets the road. It displays performance data like click-through rates and average positions. It’s your site’s report card—aim for straight A’s!
• Discover: No setup required. This tracks your site’s visibility in Google Discover. It answers the question, “Are we accidentally famous yet?”
• Google News: Enabled if your site is featured in Google News. It provides performance data for news articles, so you can see if your headlines are making headlines.

---

3. URL Inspection

• Inspect any URL: Enter any URL to check its indexing status and crawl details. It’s like asking Google, “Do you know this page exists, or is it lost in cyberspace?”

---

4. Coverage

• Errors: Automatically generated list of pages with indexing errors. These are the potholes on your website’s highway—time to get the repair crew.
• Valid with Warnings: Pages that are indexed but have issues needing attention. Consider them the teenagers of your site—mostly good but occasionally rebellious.
• Valid: Successfully indexed pages. These are your model citizens.
• Excluded: Pages intentionally not indexed. They’re in witness protection for a reason.

---

5. Sitemaps

• Submitted Sitemaps: Submit your sitemaps here to keep Google informed about your site structure. It tracks submission status and any errors—because even Google appreciates a good roadmap.
• Individual URL Submissions: Roll out the red carpet for specific pages by submitting individual URLs for crawling. Perfect for those VIP pages needing immediate attention.

---

6. Experience

• Core Web Vitals: Enabled by default, this measures user experience metrics like Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). In layman’s terms, it’s making sure your site isn’t a haunted house of slow load times and unexpected jumpscares.
• Mobile Usability: Automatically enabled, it identifies issues affecting mobile users. Because in a world where smartphones are essentially an extra limb, mobile friendliness isn’t optional.

---

7. Links

• External Links: No setup needed. It measures backlinks to your site—the digital high-fives from other websites.
• Internal Links: Auto-enabled, tracking how well your site pages connect with each other. Strong internal links are like a close-knit family—everyone supports each other.
• Top Linking Sites: Lists the domains that most frequently link to you. Think of it as your site’s fan club.
• Top Linking Text: Identifies the most common anchor text used in links to your site. It’s useful to know how others are labeling you—nicknames and all.

---

8. Enhancements

• Breadcrumbs: Implement breadcrumb structured data in your HTML to improve navigation. After all, even Hansel and Gretel needed breadcrumbs to find their way.
• FAQ: Use FAQ schema markup to help Google understand your frequently asked questions. It’s like providing the answers before the questions are even asked—a time-saver for everyone.
• How-to: Add how-to structured data to showcase your tutorial content. Teach the world to bake sourdough or change a tire—your expertise deserves the spotlight.
• Mobile Usability: Same as in the “Experience” menu, ensuring your mobile visitors aren’t dealing with tiny text and impossible buttons.
• Sitelinks Searchbox: Implement search box structured data to provide users with a search option directly in the search results. Because who doesn’t appreciate shortcuts?
• Videos: Use video schema markup to help your multimedia content shine in search results. Lights, camera, index!

---

9. Security & Manual Actions

• Security Issues: Alerts you to any security problems detected on your site. It’s the guard dog that never sleeps, keeping cyber miscreants at bay.
• Manual Actions: Displays any manual penalties imposed by Google. Hopefully, this area remains as empty as a desert island—no news is good news here.

---

10. Legacy Tools and Reports

• International Targeting: Use hreflang tags to target specific regions and languages. Whether you’re saying “Hello,” “Hola,” or “你好,” make sure your content greets users appropriately.
• Crawl Stats: Auto-generated statistics on Googlebot’s crawling activity. Ever wonder how often Google stops by? Now you can track its visits like a friendly neighbor.
• Messages: View communications from Google regarding your site. It’s like checking your mailbox—sometimes it’s good news, occasionally it’s bills.
• URL Parameters: Specify how URL parameters should be handled to affect crawl behavior. Tame those wild URL parameters before they lead Google on a wild goose chase.

---

11. Settings

• Ownership Verification: Verify ownership via HTML files, DNS records, or meta tags. It’s Google’s way of ensuring you’re the rightful captain of this ship.
• Users and Permissions: Add, remove, or modify user permissions. Control who has access—too many cooks can spoil the SEO broth.
• Change of Address: Notify Google when moving your site to a new domain. Consider it your website’s forwarding address form.
• Site Settings: Manage site settings such as crawl rate. It’s like setting your site’s cruise control for Google’s crawlers.

---

By strategically leveraging each section of Google Search Console, you can transform your website from an online presence into an SEO powerhouse. Regular check-ins with GSC will keep you ahead of potential issues and ensure your site is always performing at its peak.

Remember, in the high-stakes game of search rankings, staying informed and proactive isn’t just an advantage—it’s a necessity. So suit up, dive into GSC, and let the data guide you to the top of the search results.

---

Pro Tip: Bookmark key reports in GSC for quick access. Your future self will thank you when you’re navigating through data like a seasoned pro.

In the wild west of web protocols, the “www” prefix stands as a trusty, old sheriff. While it may seem like a nostalgic nod to the early days of the internet, there’s a solid reason we like to keep things classic with “www”. Let’s go on a little adventure, shall we?

The Importance of “www” in Domain Names

Subdomains and Organization: Picture this: subdomains are like rooms in a massive mansion. If FTP and mail have their fancy rooms, why should the apex domain be left out in the cold? By using “www,” we’re basically giving our apex domain a cozy place to live, making it protocol-agnostic and keeping things neutral.

The Classic “www” Prefix

Consistency and User Experience: “www” is more than just a prefix—it’s like the secret handshake of the internet. When you see “www,” you immediately know you’re dealing with the web’s crème de la crème. Dropping it might leave some less tech-savvy folks scratching their heads, wondering where their old friend “www” went.

Browser Behavior and Modern Practices

Modern browsers are pretty slick—they often hide “www” and the schema (http or https) to streamline your experience. But just because you don’t see it doesn’t mean it’s not doing its job. By redirecting apex domains to “www” on ports 80 and 443, we’re making sure all web traffic comes to the right party.

Embracing Web3 and Decentralization

As we tip our hats to the future with Web3 and decentralized web infrastructures, the role of domain names gets even bigger. Think of “www” as the bridge between the trusty ol’ town and the shiny new city. It’s a familiar anchor point, guiding users through the wild frontier of Web3.

Conclusion

While the internet gallops forward, certain traditions like “www” deserve their place in the hall of fame. Embracing “www” as a subdomain ensures protocol neutrality, keeps things consistent, and makes life easier for everyone. Even as we step into Web3, this classic prefix serves as the friendly guide you can count on.

So, whether you’re setting up a new website or tending to an old one, give a tip of the hat to “www”. After all, some traditions are not just worth preserving—they’re worth celebrating.