DEV Community: Stephano kambeta

Python Logging and Alerts for Scripts Nobody Is Watching

Stephano kambeta — Fri, 09 Oct 2026 10:15:00 +0000

A script that runs at 6 a.m. every day has an odd problem. You only hear from it when something goes wrong, and sometimes not even then.

No news could mean everything worked. It could also mean the script crashed, the schedule stopped, or the output was quietly wrong for a week.

This is the code companion to my guide on how to monitor your automations when something breaks, which covers the ideas. Here we build them for a Python script, using one small helper file and a GitHub Actions workflow. Everything is free to run.

The four things worth having

Each one answers a different question:

Logs tell you what happened.
Failure alerts tell you when something broke.
Result checks catch runs that finish without an error but produce the wrong result.
A heartbeat tells you when the script never ran at all.

You don't need all four for every script. Logs and a failure alert cover most small jobs. The other two are for scripts where a wrong result, or a missing run, would cost you something.

Part of the skill is knowing which scripts deserve this effort in the first place. My post on when not to automate is a useful gut check before you add monitoring to everything.

The example job

To keep this realistic, let's use a script that syncs new sign-ups from a form to a spreadsheet every morning.

It works fine at first. Then someone updates the form, the email field comes through differently, and the script keeps running without complaint. It just saves rows with no email address in them.

No error, no crash and a green checkmark. A script like this is exactly where a result check earns its place.

Step 1: Add the helper file

Create a file called watch.py:

"""Small helpers for scripts that run without anyone watching."""
import json
import logging
import os
import sys
import time
import traceback
import urllib.request
from datetime import datetime, timezone

WEBHOOK = os.environ.get("DISCORD_WEBHOOK", "")
HEARTBEAT_URL = os.environ.get("HEARTBEAT_URL", "").rstrip("/")

logging.basicConfig(level=logging.INFO, stream=sys.stdout,
                    format="%(asctime)s %(levelname)s %(message)s")
log = logging.getLogger("job")


class ResultCheck(Exception):
    """Raised when the script ran without errors, but the result looks wrong."""


def check(condition, message):
    if not condition:
        raise ResultCheck(message)


def _send(url, data=None):
    headers = {"User-Agent": "watched-job/1.0"}
    if data is not None:
        data = json.dumps(data).encode()
        headers["Content-Type"] = "application/json"
    request = urllib.request.Request(url, data=data, headers=headers)
    urllib.request.urlopen(request, timeout=15).close()


def alert(text):
    """Tell a person. A failed alert is logged, but never hides the real problem."""
    if not WEBHOOK:
        return
    try:
        _send(WEBHOOK, {"content": text[:1900]})
    except Exception as error:
        log.warning("Could not send the alert: %s", error)


def heartbeat(suffix=""):
    """Ping a heartbeat service, for example Healthchecks.io."""
    if not HEARTBEAT_URL:
        return
    for attempt in range(3):
        try:
            _send(HEARTBEAT_URL + suffix)
            return
        except Exception as error:
            log.warning("Could not send the heartbeat (attempt %d): %s", attempt + 1, error)
            time.sleep(1)


def run_link():
    """A link to this run, when running in GitHub Actions."""
    if not os.environ.get("GITHUB_RUN_ID"):
        return ""
    return "{}/{}/actions/runs/{}".format(os.environ.get("GITHUB_SERVER_URL", "https://github.com"),
                                          os.environ["GITHUB_REPOSITORY"], os.environ["GITHUB_RUN_ID"])


def run(job, name):
    """Run job() with start and finish logging, and make sure any failure is loud."""
    started = time.time()
    log.info("%s started", name)
    heartbeat("/start")
    try:
        result = job()
    except Exception as error:
        crashed = not isinstance(error, ResultCheck)
        title = f"{name} crashed" if crashed else f"{name}: the result looks wrong"
        detail = traceback.format_exc() if crashed else str(error)
        log.error("%s\n%s", title, detail)
        if os.environ.get("GITHUB_ACTIONS"):
            print(f"::error::{title}")  # shows up as a red note on the run page
        when = datetime.now(timezone.utc).strftime("%Y-%m-%d %H:%M UTC")
        alert(f"**{title}**\nWhen: {when}\n{detail[-1400:]}\n{run_link()}".strip())
        heartbeat("/fail")
        sys.exit(1)
    log.info("%s finished in %.1f seconds: %s", name, time.time() - started, result)
    if os.environ.get("GITHUB_STEP_SUMMARY"):  # a short summary on the run page
        with open(os.environ["GITHUB_STEP_SUMMARY"], "a") as summary:
            summary.write(f"### {name}\n{result}\n")
    heartbeat()
    return result

The helper has five small parts:

log writes timestamped lines to the output. GitHub Actions keeps that output for each run.
check() raises a "result looks wrong" error when a condition you care about isn't true.
alert() sends a Discord message. If the alert itself fails, that gets logged, and it never hides the original problem.
heartbeat() pings a monitoring service, with a few retries.
run() wraps your job. It logs the start and finish, catches crashes and failed checks, sends an alert, and ends the script with an error code.

That last point matters. A non-zero exit code is how a script says "this failed". Without it, a script that catches its own error and carries on looks like a success.

Step 2: Write the job

Create job.py:

import csv
import json
import os
import urllib.request

from watch import check, log, run


def job():
    with urllib.request.urlopen(os.environ["SOURCE_URL"], timeout=20) as response:
        signups = json.load(response)
    log.info("Fetched %d sign-ups", len(signups))

    if not signups:
        return "no new sign-ups today"  # a quiet day is normal, not a failure

    missing = [s for s in signups if not s.get("email")]
    check(not missing, f"{len(missing)} of {len(signups)} sign-ups have no email address. "
                       "Did the form or the API change?")

    with open("signups.csv", "w", newline="") as file:  # stand-in for your real work
        writer = csv.DictWriter(file, fieldnames=["name", "email"], extrasaction="ignore")
        writer.writeheader()
        writer.writerows(signups)
    return f"saved {len(signups)} sign-ups"


run(job, "signup-sync")

Swap the middle for your own work, like updating a spreadsheet or sending an email. The pattern stays the same:

Put the work in a function.
Log the numbers that matter.
Add a check for what "wrong" looks like.
Hand the function to run().

Notice the empty case. A quiet day with zero sign-ups is normal, so the script returns a message and carries on. If you made that a failure, you'd get false alarms, and people stop reading alerts that cry wolf.

What to put in a log

A log is a note to your future self at 7 a.m., trying to work out what happened. Write lines that help.

A healthy run looks like this:

2026-10-02 06:23:11,429 INFO signup-sync started
2026-10-02 06:23:12,031 INFO Fetched 14 sign-ups
2026-10-02 06:23:12,402 INFO signup-sync finished in 1.0 seconds: saved 14 sign-ups

Some guidelines:

Log counts, not just "done". "Fetched 14 sign-ups" is useful, and you'll notice when it suddenly says 0.
Log decisions. If the script skips something, retries something or ignores duplicates, say so and say how many.
Use the levels the way they're meant. INFO is normal, WARNING is odd but handled, and ERROR means a person should look.
Keep secrets and personal data out. Never log passwords, tokens or full webhook addresses. Log counts or IDs instead of email addresses. Logs are easy to share by accident.

Step 3: Add the workflow

Create .github/workflows/signup-sync.yml:

name: Sign-up sync

on:
  schedule:
    - cron: '23 6 * * *'   # every day at 06:23 UTC
  workflow_dispatch:        # adds a "Run workflow" button for testing

permissions:
  contents: read

jobs:
  sync:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Run the job
        env:
          SOURCE_URL: https://example.com/api/signups   # change this
          DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
          HEARTBEAT_URL: ${{ secrets.HEARTBEAT_URL }}
        run: python3 job.py

When the script exits with an error, GitHub marks the run as failed. With default notification settings, you also get an email.

Two small extras come from the helper. A failed run shows a red note at the top of the run page, and a successful one adds a one-line summary, such as "saved 14 sign-ups". You can see the result without opening the logs.

The odd start time avoids the top of the hour, when GitHub is busiest. The timeout stops a hung script from running for hours.

Step 4: Make the alert useful

Add a DISCORD_WEBHOOK secret in your repository (Settings, then Secrets and variables, then Actions). A webhook is a private address that lets a script post into a Discord channel. If the idea is new, I explain it in what a webhook is.

When something breaks, the message looks like this:

signup-sync: the result looks wrong
When: 2026-10-02 06:23 UTC
2 of 3 sign-ups have no email address. Did the form or the API change?
https://github.com/yourname/yourrepo/actions/runs/123456789

That's a deliberate shape. A good alert answers three questions: what broke, why, and when. The link on the last line takes you straight to the failed run.

An alert that only says "job failed" sends you digging. One that says what it expected and what it found often tells you the fix.

Step 5: Add a heartbeat

Everything so far only works if the script runs. What if it doesn't?

In a public repository, GitHub switches off scheduled workflows after 60 days with no repository activity. Schedules can also be disabled by mistake. In both cases there's no failed run, and no email, because nothing ran.

A heartbeat catches this. The script pings a monitoring service each time it finishes. If a ping doesn't arrive on time, the service alerts you. It's sometimes called a dead man's switch.

Healthchecks.io is one service that does this, and it has a free plan (check their pricing page for current limits). To set it up:

Create an account and add a new check
Give it a clear name, like "signup-sync"
Set the period to how often the job should run (one day for ours)
Set the grace time to how late you'll tolerate. An hour or two is sensible, because GitHub can delay scheduled runs
Choose where its alerts should go
Copy the check's ping URL and save it as a repository secret named HEARTBEAT_URL

The helper already does the rest. It sends three kinds of signal:

Start, when the job begins
Success, when it finishes properly
Fail, when it crashes or a result check fails

If a job starts but never finishes within the grace time, the service treats that as a failure too. That covers scripts that hang.

Treat the ping URL like a password, since anyone who has it can send pings to your check. The pings carry no data from your script, only the address.

If what you need to watch is a website rather than a script, I covered that in my Python uptime monitor guide, and there's a ready-made free Python uptime monitor template.

Step 6: Break it on purpose

Don't wait for a real failure to find out whether your alerts work. Run the workflow with the "Run workflow" button and try three things:

Point SOURCE_URL at an address that doesn't exist. You should get a "crashed" alert, with the error in it.
Return data with a missing email. You should get the "result looks wrong" alert.
Disable the workflow in the Actions tab and wait. After the period and grace time pass, the heartbeat service should alert you. That's the "never ran" case, and nothing else would catch it.

Then put everything back. If any of the three stays silent, you've learned something worth knowing.

Choosing good result checks

Result checks work best when they're boring. A few that suit most scripts:

Something came back when it should have. If the source normally has data every day, a total of zero is suspicious.
Required fields are there. This is the sign-up example. If a field you depend on is blank, stop.
The count is in a normal range. If you usually process 20 to 40 records, 0 and 500 are both worth a look.
The data is fresh. If the newest record is three days old, the source may have stopped updating.

These matter because the thing you depend on can change without warning. An API can start returning a different format, and your script keeps running as if nothing happened.

Pick checks that wouldn't fire on a normal quiet day. If a check fails often for harmless reasons, you'll learn to ignore it.

What can go wrong

Too many alerts. If every small hiccup pings you, you'll mute the channel. Alert only on things you'd act on, and let minor ones sit in the log.

Checks that are too strict. A rule that fires every weekend gets disabled. Tune it until a failure always means something.

The alert channel is broken. If someone deletes the webhook, your alerts go nowhere. The script logs a warning, and the heartbeat service still has its own way of reaching you. That's one reason to have both.

Secrets in logs. Print counts and IDs, not tokens or personal details. Look through a few real logs after the first runs.

A script that hides its own errors. If you wrap code in try/except and carry on, the run looks fine. Let errors reach run(), or call check().

Quick answers

Why not just rely on GitHub's failure emails?
They only cover runs that fail. They don't catch a run that finishes with the wrong result, or a schedule that stopped, and they're easy to miss in a busy inbox.

Do I need all four parts?
No. Start with logs and a failure alert. Add a result check where wrong data would cost you, and a heartbeat for scheduled scripts you depend on.

Can I use Slack or Telegram instead of Discord?
Yes. Change the alert() function to match what that service expects. The rest stays the same.

Does it work outside GitHub Actions?
Yes. The helper works anywhere Python runs, such as cron on a server. The run link, red note and summary only appear inside GitHub Actions.

Does it cost anything?
The workflow is free on a public repository and uses a few minutes a month on a private one. Healthchecks.io has a free plan, but check its current limits.

The short version

A script nobody watches needs to speak up for itself. Logs show what happened, alerts say when it broke, result checks catch wrong answers, and a heartbeat notices when it goes quiet.

Start small. Add the helper, wrap one important script and break it on purpose to see what happens.

You can find more practical automation guides on Procwire.

Weekly GitHub Repo Digest in Discord: Stars, Issues, Traffic

Stephano kambeta — Thu, 08 Oct 2026 10:00:00 +0000

Someone opens a bug report on Monday. Nobody sees it, because GitHub's notification emails are buried under everything else. By the time you check, it has been sitting there for nine days.

Small projects don't usually fail loudly. They drift. Issues pile up, a post brings in a burst of visitors you never notice, and a week of silence turns into a month.

A short weekly summary fixes a lot of that. This guide builds one: a Python script and a GitHub Actions workflow that post a digest to Discord every Monday. It's free and needs no server.

What the digest looks like

Here's an example of what lands in your Discord channel (the numbers ar

e made up):

Weekly digest: yourname/your-project
Stars: 124 total, +5 this week
Forks: 12 total, +1 this week
Issues: 7 open, 2 opened and 3 closed this week
Views: 340 | Clones: 22 (this week)
Top referrers (last 14 days): dev.to (80), Google (40), github.com (10)
https://github.com/yourname/your-project

It's seven lines. You can read it in ten seconds, and it answers the questions people actually have: is anyone noticing this project, and is anything waiting for me?

A digest tells you what changed. It doesn't tell you when something breaks. For that, a monitor is the better tool, and I covered how to build one in my guide to a free Python uptime monitor. The two work well together.

What you need

A GitHub repository to put the script in. It can be the project you want to track
A Discord server where you can add a webhook (a private one just for you works well)
Optional: a personal access token, if you want the traffic numbers

The script uses only what Python already includes, so there's nothing to install.

A note on traffic numbers

Stars, forks and issues are easy to read. Traffic is the awkward one, and it's worth understanding before you start.

The built-in token that every workflow gets can't read a repository's traffic. GitHub only allows it with a personal access token that has "Administration" read permission, and there's no narrower option. The permission is read-only, but it does sound bigger than it is.

GitHub also keeps traffic data for only the last 14 days. That's why the digest labels the referrers "last 14 days".

So you have two choices:

Skip traffic. Everything else still works with the built-in token, and the digest says traffic was skipped.
Add a token. I'll show how in Step 3. Limit it to the repositories you need, and give it an expiry date.

Either way is fine. Many people start without traffic and add it later.

Step 1: Add the script

Create a file called weekly_digest.py in your repository:

import json
import os
import re
import sys
import urllib.error
import urllib.parse
import urllib.request
from datetime import datetime, timedelta, timezone

API = os.environ.get("GITHUB_API_URL", "https://api.github.com")  # set automatically in GitHub Actions
TOKEN = os.environ["GH_TOKEN"]
REPOS = (os.environ.get("REPOS") or os.environ["GITHUB_REPOSITORY"]).split(",")
DAYS = int(os.environ.get("DAYS", "7"))
WEBHOOK = os.environ.get("DISCORD_WEBHOOK", "")

since = datetime.now(timezone.utc) - timedelta(days=DAYS)
since_time = since.strftime("%Y-%m-%dT%H:%M:%SZ")
since_day = since.strftime("%Y-%m-%d")
period = "this week" if DAYS == 7 else f"in the last {DAYS} days"
STAR_FORMAT = "application/vnd.github.star+json"  # adds the date each star was given


def api(path, accept="application/vnd.github+json"):
    request = urllib.request.Request(API + path, headers={
        "Authorization": f"Bearer {TOKEN}",
        "Accept": accept,
        "X-GitHub-Api-Version": "2022-11-28",
        "User-Agent": "weekly-digest",
    })
    with urllib.request.urlopen(request, timeout=20) as response:
        return json.load(response), response.headers


def new_stars(repo):
    _, headers = api(f"/repos/{repo}/stargazers?per_page=100", STAR_FORMAT)
    last = re.search(r'[?&]page=(\d+)>; rel="last"', headers.get("Link", ""))
    page, count = (int(last.group(1)) if last else 1), 0
    while page >= 1:  # start with the newest stars and work backwards
        stars, _ = api(f"/repos/{repo}/stargazers?per_page=100&page={page}", STAR_FORMAT)
        count += sum(1 for s in stars if s["starred_at"] >= since_time)
        if any(s["starred_at"] < since_time for s in stars):
            break  # everything before this page is older still
        page -= 1
    return count


def new_forks(repo):
    forks, _ = api(f"/repos/{repo}/forks?sort=newest&per_page=100")
    return sum(1 for f in forks if f["created_at"] >= since_time)


def count_issues(repo, filter_):
    query = urllib.parse.quote(f"repo:{repo} is:issue {filter_}")
    data, _ = api(f"/search/issues?per_page=1&q={query}")
    return data["total_count"]


def days_total(data, key):
    return sum(day["count"] for day in data[key] if day["timestamp"][:10] > since_day)


def traffic_lines(repo):
    try:
        views, _ = api(f"/repos/{repo}/traffic/views")
        clones, _ = api(f"/repos/{repo}/traffic/clones")
        sources, _ = api(f"/repos/{repo}/traffic/popular/referrers")
    except urllib.error.HTTPError as error:
        if error.code not in (403, 404):
            raise
        return ["Traffic: skipped (this token can't read it)"]
    lines = [f"Views: {days_total(views, 'views')} | Clones: {days_total(clones, 'clones')} ({period})"]
    if sources:
        top = ", ".join(f"{s['referrer']} ({s['count']})" for s in sources[:3])
        lines.append(f"Top referrers (last 14 days): {top}")
    return lines


def build_digest(repo):
    info, _ = api(f"/repos/{repo}")
    return "\n".join([
        f"**Weekly digest: {repo}**",
        f"Stars: {info['stargazers_count']} total, +{new_stars(repo)} {period}",
        f"Forks: {info['forks_count']} total, +{new_forks(repo)} {period}",
        f"Issues: {count_issues(repo, 'is:open')} open, "
        f"{count_issues(repo, f'created:>={since_day}')} opened and "
        f"{count_issues(repo, f'closed:>={since_day}')} closed {period}",
        *traffic_lines(repo),
        info["html_url"],
    ])


def send(text):
    if not WEBHOOK:
        print(text + "\n")
        return
    body = json.dumps({"content": text[:1900]}).encode()
    # Discord turns away requests with Python's default User-Agent, so we set our own
    request = urllib.request.Request(WEBHOOK, data=body, headers={
        "Content-Type": "application/json", "User-Agent": "weekly-digest/1.0"})
    urllib.request.urlopen(request, timeout=15).close()


errors = []
for repo in (r.strip() for r in REPOS):
    try:
        send(build_digest(repo))
    except Exception as error:
        errors.append(f"{repo}: {error}")

if errors:
    print("Problems:", *errors, sep="\n- ")
    sys.exit(1)

The script talks to GitHub through its API, the set of web addresses that tools use to ask GitHub for data. If that's new to you, my beginner's guide to what an API is explains the idea.

Here's what it does for each repository:

Stars. It looks at when each star was given and counts the ones from the last 7 days. It starts from the newest stars and stops as soon as it reaches older ones, so big repositories stay fast.
Forks. It counts the new forks in the same period.
Issues. It counts how many are open, how many were opened and how many were closed. Pull requests aren't included, only issues.
Traffic. It adds views, clones and top referrers, if the token allows it.
Delivery. It posts the result to Discord.

If one repository fails, for example because of a typo in its name, the others are still sent and the run is marked as failed at the end so you hear about it.

Step 2: Add the workflow

Create .github/workflows/weekly-digest.yml:

name: Weekly repo digest

on:
  schedule:
    - cron: '37 7 * * 1'   # Mondays at 07:37 UTC
  workflow_dispatch:        # adds a "Run workflow" button for testing

permissions:
  contents: read
  issues: read

jobs:
  digest:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Send the digest
        env:
          GH_TOKEN: ${{ secrets.DIGEST_TOKEN || github.token }}
          DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
          # REPOS: owner/repo-one,owner/repo-two   # optional, see below
        run: python3 weekly_digest.py

A few notes:

Which repository? By default it reports on the repository the workflow lives in. To watch others, uncomment REPOS and list them, separated by commas.
The token line. secrets.DIGEST_TOKEN || github.token means "use my own token if I added one, otherwise use the built-in one". That's how traffic stays optional.
Limited permissions. The workflow can read your code and issues and nothing else.
The odd start time avoids the top of the hour, when GitHub is busiest and scheduled runs are more likely to be delayed.
The schedule. 1 at the end means Monday. Each run takes a few seconds and is billed as one minute, so a weekly digest uses about 4 or 5 minutes a month.

Step 3: Add your secrets

In your repository, open Settings, then Secrets and variables, then Actions, and add:

DISCORD_WEBHOOK (required). A webhook is a private address that lets a script post into a Discord channel. In Discord, open the channel's settings, go to Integrations, then Webhooks, create one and copy its address. If webhooks are new to you, here's what a webhook is and how it works. Treat the address like a password, because anyone who has it can post to your channel.

DIGEST_TOKEN (optional, for traffic). To create it:

On GitHub, open your account Settings, then Developer settings, then Personal access tokens, then Fine-grained tokens
Create a new token and give it a clear name, like "weekly digest"
Set an expiry date
Under repository access, choose "Only select repositories" and pick the ones you want to track
Under repository permissions, set "Administration" to read-only
Create the token, copy it straight away and save it as the DIGEST_TOKEN secret

The token is read-only and limited to your chosen repositories. It will expire, so put a reminder in your calendar. When it does, the workflow fails with an authentication error, and you create a new token and update the secret.

Step 4: Test it

Open the Actions tab in your repository, choose "Weekly repo digest" and click "Run workflow". Within a minute or so, the digest should appear in Discord.

If you'd rather see the output first, run it on your computer with the webhook left out, and the digest prints in your terminal. Set GH_TOKEN to a token and GITHUB_REPOSITORY to your repository, for example yourname/your-project.

Reading the numbers

A digest is only useful if it changes what you do.

Stars are a mood, not a goal. A jump usually means someone shared your project. Look at the referrers to find out where.
Referrers tell you what's working. If most visitors arrive from one article or site, that's where your next post should go.
Views and clones are different things. Views are people looking at your pages. Clones can include automated systems, like build servers, so don't read them as readers.
Opened vs closed matters more than open. If more issues are opened than closed for several weeks in a row, the pile is growing. That's the signal to set aside an hour.
Quiet weeks are normal. Zero stars and two views is a perfectly ordinary week for a small project.

The script leaves out unique visitors on purpose. GitHub counts them per day, so adding the days together would count the same person several times.

Is this worth automating?

For most people with a project, yes. A digest is a good example of something that suits automation: it's repetitive, it only reads data, and a mistake costs almost nothing. The worst case is a wrong number in a Discord message.

I wrote about how to judge other tasks in When Not to Automate: 6 Signs a Task Isn't Worth It.

What can go wrong

Traffic says "skipped". The token can't read it. Check that DIGEST_TOKEN exists, covers that repository, and has Administration set to read-only.

The run fails with an authentication error. Your token has probably expired, or it was deleted. Create a new one and update the secret.

A private repository returns "not found". The token doesn't have access to it. Add the repository to the token's list.

Too many repositories. The issue counts use GitHub's search, which has a lower request limit than the rest of the API. A handful of repositories is fine. A very long list may run into it.

The digest stops arriving. In a public repository, GitHub switches off scheduled workflows after 60 days without repository activity. If Monday comes and goes with nothing in Discord, check the Actions tab. I go into this more in how to monitor your automations when something breaks.

Quick answers

Can I get this by email instead?
Sending email from a workflow needs mail account details, which is more setup. Discord, Slack or Telegram are simpler because they only need a webhook or a bot token.

Can I use Slack instead of Discord?
Yes, if you change the message format. Slack's incoming webhooks expect {"text": "..."} instead of Discord's {"content": "..."}, so you'd edit the send function.

Can I track someone else's repository?
You can read the stars, forks and issues of public repositories. Traffic is only available for repositories you have access to.

Why do the traffic numbers only go back 14 days?
That's GitHub's limit. If you want a longer history, you'd need to save the numbers somewhere each week.

Does it cost anything?
No. Public repositories don't use up any free minutes, and a weekly run is tiny on a private one.

The short version

Most projects don't need a dashboard. They need a short message once a week that says what changed and what's waiting.

Start without the token, since stars, forks and issues are enough to be useful. Add traffic later if you want it.

You can find more practical automation guides on Procwire.

Cross-Post Your Blog to DEV and Bluesky Automatically

Stephano kambeta — Wed, 07 Oct 2026 10:00:00 +0000

A new blog post goes live on Tuesday. By Thursday it has been shared on one platform and forgotten on the other two.

Writing the article is the hard part. Copying the title, pasting the link and reformatting it for each site is the boring part, and it's the first thing to slip when you're busy.

This guide sets up a simple routine: publish once on your own blog, and let your RSS feed carry the post to DEV and Bluesky. DEV needs no code at all. Bluesky needs one short Python script and a GitHub Actions workflow, and both are free.

The plan

Your blog is the home of every article. Everything else follows from it.

DEV: its built-in RSS import creates a draft of each new post. You review it and publish.
Bluesky: a script checks your feed every few hours and shares each new article once, with a link card.

Why RSS? Almost every blog platform produces a feed, so this works whether you use WordPress, Ghost, Hugo or something else. It's also a plain, stable format, so there's very little to break.

A link on its own is only part of the story, though. Near the end of Part 2, I'll cover what to do when you want more than a link, like an X thread or a LinkedIn draft for each article.

Do you have a feed?

Your RSS or Atom feed is a web address that lists your latest posts as data. Common places to find it are /rss.xml, /feed and /feed.xml on your site. If none of those work, check your blog platform's settings or documentation.

Open the address in your browser. You should see a page of structured text with your recent post titles and links in it.

Part 1: Import posts into DEV (no code)

DEV can watch your feed and create a draft whenever you publish something new.

In DEV, open Settings, then Extensions
Find the section called "Publishing to DEV Community from RSS"
Paste your feed address
Tick "Mark the RSS source as canonical URL by default"
Click to submit the feed settings, then use "Fetch feed now" to test it

New posts then show up as drafts in your DEV dashboard. Nothing is published until you say so.

The canonical URL option is the one that matters. It tells search engines that your blog holds the original version, so your site gets the credit and the DEV copy isn't treated as a competing duplicate. Leave "Replace links with DEV Community links" unchecked if you want internal links to keep pointing to your own site.

A few things worth knowing about how DEV reads your feed:

It uses the full article from the feed's content when there is one. If your feed only has short summaries, your drafts will be short too.
The first four categories or tags on each item become the post's tags.
The HTML is converted to Markdown, so look over each draft before you publish. Code blocks and images are the usual places to check.

Importing as drafts is a feature, not a limit. It gives you a moment to fix formatting and add a short intro for the DEV audience.

Part 2: Share new posts on Bluesky

DEV has a built-in tool for this job. Bluesky doesn't, so a small script fills the gap.

You could build this half in a no-code tool like Zapier. A scheduled GitHub Actions workflow does the same job for free, and I compared the two in Zapier vs GitHub Actions for small business workflows if you're deciding.

Before you start

A Bluesky account
A GitHub repository for the script (a new, empty one is fine)
An app password for Bluesky. In Bluesky, open Settings, then Privacy and security, then App passwords, and create one. It's a separate password that works for scripts, and you can cancel it at any time without touching your real password. My Bluesky automation bot guide walks through this step with screenshots

The script uses only what Python already includes, so there's nothing to install.

It talks to Bluesky through its API, which is a set of web addresses that apps use to send each other requests. If that idea is new, what an API is and how apps talk to each other explains it in plain language.

Step 1: Add the script

Create a file called post_new_articles.py:

import html
import json
import os
import re
import sys
import urllib.request
import xml.etree.ElementTree as ET
from datetime import datetime, timezone

FEED_URL = os.environ["FEED_URL"]
HANDLE = os.environ["BSKY_HANDLE"]
APP_PASSWORD = os.environ["BSKY_APP_PASSWORD"]
SERVICE = os.environ.get("BSKY_SERVICE", "https://bsky.social")  # change only if you use another server
MAX_PER_RUN = 3
STATE_FILE = "posted.json"


def fetch(url, data=None, token=None):
    headers = {"User-Agent": "feed-to-bluesky/1.0"}
    if data is not None:
        data = json.dumps(data).encode()
        headers["Content-Type"] = "application/json"
    if token:
        headers["Authorization"] = f"Bearer {token}"
    request = urllib.request.Request(url, data=data, headers=headers)
    with urllib.request.urlopen(request, timeout=20) as response:
        return response.read()


def call(method, data, token=None):
    return json.loads(fetch(f"{SERVICE}/xrpc/{method}", data, token))


def clean(text, limit):
    """Remove HTML tags and extra spaces, and cut the text to a maximum length."""
    text = html.unescape(re.sub(r"<[^>]+>", "", text or ""))
    text = " ".join(text.split())
    return text if len(text) <= limit else text[: limit - 1].rstrip() + "…"


def read_feed(url):
    """Return the posts in an RSS or Atom feed, newest first."""
    root = ET.fromstring(fetch(url))
    posts = []
    for entry in root.iter():
        if entry.tag.split("}")[-1] not in ("item", "entry"):
            continue
        post = {}
        for child in entry:
            name = child.tag.split("}")[-1]
            if name == "link" and "link" not in post:
                post["link"] = (child.get("href") or child.text or "").strip()
            elif name in ("title", "description", "summary") and name not in post:
                post[name] = child.text or ""
        if post.get("link") and post.get("title"):
            posts.append(post)
    return posts


posts = read_feed(FEED_URL)
first_run = not os.path.exists(STATE_FILE)
seen = [] if first_run else json.load(open(STATE_FILE))
new = [p for p in posts if p["link"] not in seen]

if first_run:
    # Don't flood your timeline with old posts the first time
    print(f"First run: remembering {len(new)} existing posts. Nothing is posted.")
    seen += [p["link"] for p in new]
    new = []

to_post, skipped = new[:MAX_PER_RUN], new[MAX_PER_RUN:]
seen += [p["link"] for p in skipped]  # too old to be worth posting now
errors, session = [], None

for post in reversed(to_post):  # oldest first, so the timeline reads in order
    try:
        if session is None:
            session = call("com.atproto.server.createSession",
                           {"identifier": HANDLE, "password": APP_PASSWORD})
        title = clean(post["title"], 250)
        record = {
            "$type": "app.bsky.feed.post",
            "text": f"New article: {title}",
            "createdAt": datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ"),
            "embed": {
                "$type": "app.bsky.embed.external",
                "external": {
                    "uri": post["link"],
                    "title": title,
                    "description": clean(post.get("description") or post.get("summary"), 200),
                },
            },
        }
        call("com.atproto.repo.createRecord",
             {"repo": session["did"], "collection": "app.bsky.feed.post", "record": record},
             session["accessJwt"])
        seen.append(post["link"])
        print("Posted:", title)
    except Exception as error:
        errors.append(f"{post['title']}: {error}")  # not remembered, so the next run tries again

with open(STATE_FILE, "w") as file:
    json.dump(seen[-200:], file, indent=2)

if not new:
    print("No new posts.")
if skipped:
    print(f"Skipped {len(skipped)} older new posts (limit is {MAX_PER_RUN} per run).")
if errors:
    print("Problems:", *errors, sep="\n- ")
    sys.exit(1)

Here's what it does:

It reads your feed and finds the posts it hasn't shared yet.
It logs in to Bluesky with your app password, but only when there's something to post.
For each new article, it posts a short line with a link card showing the title and description.
It saves the list of shared posts in posted.json, so nothing is posted twice.

A few choices keep it from causing trouble:

The first run posts nothing. It just remembers what's already in your feed. Otherwise your timeline would fill up with your whole archive.
At most 3 posts per run. If you publish a batch, the script won't flood your followers. Older ones in the batch are skipped.
Oldest first. If two articles are new, they appear in the order you published them.
Failed posts are retried. If Bluesky is down, the article isn't marked as shared, so the next run tries again.

It also reads Atom feeds, not just RSS.

Step 2: Add the workflow

Create .github/workflows/share-articles.yml:

name: Share new articles on Bluesky

on:
  schedule:
    - cron: '11 */3 * * *'   # every 3 hours, at 11 minutes past
  workflow_dispatch:          # adds a "Run workflow" button for testing

concurrency:
  group: share-articles       # never run two at the same time

permissions:
  contents: write             # needed to save posted.json

jobs:
  share:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Post new articles
        env:
          FEED_URL: https://example.com/rss.xml     # change this
          BSKY_HANDLE: yourname.bsky.social          # change this
          BSKY_APP_PASSWORD: ${{ secrets.BSKY_APP_PASSWORD }}
        run: python3 post_new_articles.py

      - name: Save the list of shared posts
        if: always()
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add posted.json
          git diff --staged --quiet || git commit -m "Update shared posts"
          git push

Change FEED_URL and BSKY_HANDLE to your own. Then add your app password as a repository secret: in your repo, open Settings, then Secrets and variables, then Actions, and create a secret named BSKY_APP_PASSWORD. Never paste it into a file.

Some notes on the workflow:

Why contents: write? GitHub Actions has no memory between runs, so the workflow saves posted.json back to your repository. It only makes a commit when the list changes.
Why every 3 hours? A blog posts a few times a week at most. Eight quick checks a day is plenty, and it costs about 240 minutes a month. That's nothing on a public repository.
The odd start time avoids the top of the hour, when GitHub is busiest.

Step 3: Test it

Open the Actions tab in your repository, choose "Share new articles on Bluesky" and click "Run workflow".

The first run should finish with a message like "First run: remembering 12 existing posts. Nothing is posted." That's correct. It now has a baseline.

To see a real post, you have two options:

Publish a new article and run the workflow again, or wait for the next scheduled run
Open posted.json in your repository and delete the line for your latest article. The next run treats it as new and posts it

If it works, you'll see a post on your Bluesky profile with the article's title and a clickable card.

When a link isn't enough

The script announces each article with its title and a link. That's a fine way to tell Bluesky about it, but every platform has its own style. A thread on X reads differently from a LinkedIn post, and a newsletter teaser is a third thing again.

Writing all of those by hand for every article is the step that usually gets skipped.

Full disclosure: I sell a tool for exactly this, called Repurpose Bot. Here's what it does, and where it may not be the right fit.

It watches your blog's RSS or Atom feed, the same way the script above does. When a new post appears, it asks an AI model to write:

An X thread of 5 to 7 posts, with a hook at the start and your link at the end
A LinkedIn post of 150 to 250 words
A newsletter blurb of 2 to 3 sentences

It then sends those drafts to Telegram, Discord or Slack, whichever you already use. Discord and Slack deliver messages through webhooks. If that term is new, I explain it in what a webhook is.

A few details worth knowing:

It sends drafts, not posts. Nothing is published to X or LinkedIn on its own. You read each draft, adjust it and post it yourself, which is a good habit with AI-written text anyway. (Direct posting is something I can build as custom work.)
The first run is safe. It skips the posts already in your feed, so you don't get a pile of drafts for your whole archive.
Costs stay predictable. A per-run limit caps how many posts it handles at once.
It runs on GitHub Actions, the same free setup as the Bluesky script, and you bring your own OpenAI or Gemini key. The AI provider bills you directly for usage.
Settings live in one file. Tone, formats, models and delivery channels are all in config.yaml, and adding another format, like an Instagram caption, takes three lines.
Price: a one-time $29, with no subscription. Setup takes about 10 minutes in the browser.

If all you want is your article's link on Bluesky, the free script in this guide is enough. Repurpose Bot is for the case where you want the thread, the LinkedIn post and the newsletter teaser drafted for you, and you're happy to review them.

You can also build it yourself. The feed reading and the "never post twice" logic are already in the script above, and you'd add a call to an AI provider. The parts that take the longest are the unglamorous ones: retrying failed requests, limiting how many posts go out at once, and splitting long messages to fit each platform.

If you write on DEV first

Some people publish on DEV first and want Bluesky to follow. That works too. DEV gives every account a feed, and you can point the script at it:

https://dev.to/feed/your-username

Use that address as FEED_URL, and each new DEV post gets shared on Bluesky.

What can go wrong

Your feed has summaries only. DEV drafts will be short, and you'll need to paste in the rest. Check whether your blog platform can include the full article in the feed.

The link card has no image. The script keeps things simple and shares the title and description only. Adding a picture means uploading it to Bluesky first, which is doable but adds code.

Your app password stops working. If you cancel it or change your handle, the run fails and GitHub emails you. That's the right outcome, since the alternative is silence.

The state file is lost. If posted.json is deleted, the script treats your next run as a first run and posts nothing, then starts fresh. It won't re-share your archive.

The workflow gets switched off. In a public repository, GitHub disables scheduled workflows after 60 days with no repository activity. If new posts stop appearing on Bluesky, check the Actions tab. I go into this more in how to monitor your automations when something breaks.

A note on good behavior

Automation makes posting easy, but it's still your account and your followers.

One post per article is plenty. Don't add extra automated posts that repeat the same link, and don't let a bug post the same thing ten times. The "never post twice" and "three at most" rules in the script exist for that reason.

It's also worth asking whether a task should be automated at all. Announcing a new article is a good fit, because it's repetitive, predictable and low risk. For tasks that need judgment, a person should stay involved. I wrote about how to tell the difference in When Not to Automate: 6 Signs a Task Isn't Worth It.

Quick answers

Will DEV publish my posts automatically?
No. Imported posts arrive as drafts, and you publish them yourself.

Will cross-posting hurt my search ranking?
Setting the canonical URL tells search engines which copy is the original. With the box ticked, DEV marks your blog as the source.

Can I import my old posts?
DEV's feed import will pick up what's in your feed. For Bluesky, the script deliberately skips old posts on the first run.

What if I publish several posts in one day?
The script shares up to 3 per run, oldest first. Anything beyond that in the same run is skipped.

Can I get an X thread or a LinkedIn post written for each article?
That's a different job from sharing a link. Repurpose Bot does it: it writes an X thread, a LinkedIn post and a newsletter blurb for each new post and sends the drafts to Telegram, Discord or Slack for you to review. It's a paid product. The Bluesky script in this guide stays free.

Can I use this for another platform?
If the platform has an API for posting, the same idea works: read the feed, remember what's been shared, post the rest. Only the posting step changes.

Does it cost anything?
No. A run every 3 hours uses about 240 minutes a month, which is free on a public repository and a small slice of the allowance on a private one.

The short version

Publishing in more than one place shouldn't mean doing the same work three times. Let your blog be the original, let DEV import it as a draft, and let a small script announce it on Bluesky.

Start with the DEV import, since it takes five minutes and needs no code. Add the Bluesky script when you're ready.

You can find more practical automation guides on Procwire.

Build a Free Price Tracker with Python and Discord Alerts

Stephano kambeta — Tue, 06 Oct 2026 10:00:00 +0000

Anyone who pays a supplier in another currency ends up watching one number: the exchange rate. It moves up and down all week, and the good days are easy to miss.

Checking it by hand means remembering to look. Most of the time you forget, or you look at the wrong moment.

A small script can watch it for you and send a message only when the number reaches the level you picked. This guide builds one with Python, GitHub Actions and Discord. It's free, and it works for any price that a website or service publishes as data.

What it does

Every few hours, the tracker:

Reads a list of prices you want to watch
Fetches each one
Compares it to your target
Sends a Discord message the moment a price reaches the target

The important part is the last step. It sends one message when the price crosses your target, not one every time it runs. If the price stays below your target for a week, you get a single alert, not 28.

Where do the prices come from?

This is the part to think about first.

The easiest and most reliable source is a public data feed: a web address that returns the price as structured data (JSON) instead of a web page. Exchange rates, crypto prices and many supplier or marketplace services offer this.

Scraping the HTML of a shop's product page is a different story. It often breaks when the site changes its layout, many shops block automated visitors, and some forbid it in their terms of use. If a shop doesn't offer a feed, check its terms and look for a built-in price alert before you build anything against its pages.

This guide works with feeds only. For the example, I'll use the Frankfurter API, a free service for exchange rates based on European Central Bank data. It needs no account and no API key.

What you need

A GitHub repository for the tracker (a new, empty one is fine)
A Discord server where you can add a webhook (a private one just for you works well)
The address of a price feed. I'll use the exchange rate feed to start

The script uses only what Python already includes, so there's nothing to install.

Step 1: List what you want to watch

Create a file called items.json:

[
  {
    "name": "EUR to USD",
    "url": "https://api.frankfurter.dev/v1/latest?base=EUR&symbols=USD",
    "path": "rates.USD",
    "target": 1.20,
    "alert_when": "above"
  }
]

Each item has these parts:

name: how it appears in your alert
url: the address of the feed
path: where the price sits inside the data, with dots between the steps
target: the number you're waiting for
alert_when: "above" or "below". If you leave it out, it defaults to "below", which suits a product you want to buy cheaper

Here, the feed returns something like {"base": "EUR", "date": "...", "rates": {"USD": 1.17}}. The path rates.USD walks into rates, then picks USD.

Pick a target that suits you. If the price already meets it the first time the tracker runs, you'll get an alert right away.

Step 2: Add the script

Create check_prices.py:

import json
import os
import sys
import urllib.request

WEBHOOK = os.environ.get("DISCORD_WEBHOOK", "")
# Discord turns away requests with Python's default User-Agent, so we set our own
HEADERS = {"User-Agent": "price-tracker/1.0", "Content-Type": "application/json"}


def get_json(url):
    request = urllib.request.Request(url, headers=HEADERS)
    with urllib.request.urlopen(request, timeout=15) as response:
        return json.load(response)


def find_price(data, path):
    """Follow a path like 'rates.USD' or 'items.0.price' into the JSON."""
    for key in path.split("."):
        data = data[int(key)] if isinstance(data, list) else data[key]
    return float(data)


def send_alert(text):
    if not WEBHOOK:
        print("ALERT (no webhook set):", text)
        return
    body = json.dumps({"content": text}).encode()
    request = urllib.request.Request(WEBHOOK, data=body, headers=HEADERS)
    urllib.request.urlopen(request, timeout=15).close()


items = json.load(open("items.json"))
state = json.load(open("prices.json")) if os.path.exists("prices.json") else {}
errors = []

for item in items:
    name = item["name"]
    try:
        price = find_price(get_json(item["url"]), item["path"])
    except Exception as error:
        errors.append(f"{name}: {error}")
        continue

    mode = item.get("alert_when", "below")
    hit = price <= item["target"] if mode == "below" else price >= item["target"]
    was_hit = state.get(name, {}).get("hit", False)
    print(f"{name}: {price} (target: {mode} {item['target']})")

    if hit and not was_hit:
        try:
            send_alert(f"{name} is now {price} ({mode} your target of {item['target']})")
        except Exception as error:
            errors.append(f"{name}: could not send the alert ({error})")
            continue  # don't record the hit, so we try again next run
    state[name] = {"price": price, "hit": hit}

with open("prices.json", "w") as file:
    json.dump(state, file, indent=2, sort_keys=True)

if errors:
    print("Could not check:", *errors, sep="\n- ")
    sys.exit(1)

Here's how it works:

It loads your list and a small file called prices.json, where it remembers what happened last time.
For each item, it fetches the price and checks it against the target.
It sends an alert only if the target is met now and wasn't met last time.
It saves the latest prices and whether each one is "on target."

That memory is what stops the repeat alerts. If a price goes above your target and later drops back, you'll be told again the next time it crosses.

Two details make it more dependable:

One broken item doesn't stop the rest. Problems are collected, the other items still get checked, and the run is marked as failed at the end so you hear about it.
A failed alert is retried. If Discord can't be reached, the tracker doesn't record that the alert was sent, so it tries again on the next run.

Step 3: Add the workflow

Create .github/workflows/price-tracker.yml:

name: Price tracker

on:
  schedule:
    - cron: '17 */6 * * *'   # every 6 hours, at 17 minutes past
  workflow_dispatch:          # adds a "Run workflow" button for testing

concurrency:
  group: price-tracker        # never run two checks at the same time

permissions:
  contents: write             # needed to save prices.json

jobs:
  track:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Check prices
        env:
          DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
        run: python3 check_prices.py

      - name: Save prices
        if: always()
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add prices.json
          git diff --staged --quiet || git commit -m "Update prices"
          git push

A few notes on this:

Why contents: write? GitHub Actions starts fresh every time, so the tracker has no memory between runs. This saves prices.json back into your repository. It only makes a commit when something actually changed.
A free bonus. Because each change is saved as a commit, your repository ends up holding a price history you can look back through.
Why every 6 hours? The exchange rate feed updates once per working day, so checking more often wouldn't show anything new. Match the schedule to how often your feed changes.
always() on the save step means the prices are saved even when one item fails.

Step 4: Set up the Discord webhook

A webhook is a private address that lets a script post into a Discord channel. (I explain the idea in my beginner guide to webhooks.)

In Discord, open the settings for the channel you want alerts in
Go to Integrations, then Webhooks, and create a new webhook
Copy the webhook address
In your GitHub repository, open Settings, then Secrets and variables, then Actions
Add a new repository secret named DISCORD_WEBHOOK and paste the address in

Keep the address secret. Anyone who has it can post to your channel, so never paste it into a file in your repository.

Step 5: Test it

Try it on your own computer first. Run this in the folder with your files:

python3 check_prices.py

With no webhook set, an alert prints in your terminal instead of going to Discord. You'll see a line like EUR to USD: 1.17 (target: above 1.2).

Then test the real thing. In your repository, open the Actions tab, choose "Price tracker" and click "Run workflow". To force an alert, set the target somewhere the price has already passed, for example "target": 0.5 with "alert_when": "above". You should get a Discord message within a minute. Put your real target back afterwards.

Adding your own prices

To track something else, add another block to items.json:

{
  "name": "My supplier's part",
  "url": "https://your-supplier.example.com/api/products/123",
  "path": "data.price",
  "target": 19.99
}

The address above is a placeholder, so swap in a real feed. To find the path:

Open the feed address in your browser
Look at the data it returns and find the price
Write down the names you pass through to reach it, separated by dots

If the price sits inside a list, use a number for the position, starting at 0. For example, items.0.price means "the first entry in items, then its price."

How often should it check?

Match the schedule to how often the price changes.

An exchange rate that updates once a day doesn't need a check every 10 minutes. A shop that changes prices a few times a week needs even less.

Checking too often doesn't give you better alerts. It uses your free minutes and puts extra load on someone else's server. A few times a day is enough for most things.

What can go wrong

The feed changes its format. If the price moves to a different spot in the data, the tracker can't find it and the run fails. That's a good outcome, because you get a failure email and know to update the path.

The price is tied to something else. Some feeds give prices before tax, or in a different currency, or per pack instead of per item. Check what the number really means before you trust it.

The feed limits how often you can ask. Some services allow only a certain number of requests. If yours does, check less often.

You stop hearing anything. Silence could mean prices never hit your target, or it could mean the tracker stopped. In a public repository, GitHub switches off scheduled workflows after 60 days without repository activity. Now and then, look at the Actions tab. I cover this in how to monitor your automations when something breaks.

Quick answers

Can I track a product on any online shop?
Only if the shop offers a price feed you're allowed to use. Scraping product pages is fragile, and some shops forbid it. Check the terms first, or use the shop's own price alert if it has one.

Will I get spammed with alerts?
No. You're alerted once when the price crosses your target, then again only after it has left the target zone and come back.

Does it cost anything?
No. A run every 6 hours uses about 120 minutes a month, which is nothing on a public repository and a small part of the free allowance on a private one. Discord webhooks are free.

Can I get alerts somewhere other than Discord?
Yes, if the place supports webhooks. You'd change the message format inside send_alert to match what that service expects.

The short version

A price you have to remember to check is a price you'll miss. A small script that watches it and tells you once turns it into something you can forget about until it matters.

Start with one item and get it working. Add more when you trust it.

You can find more practical automation guides on Procwire. If you'd like a check for your own website next, my Python uptime monitor guide is a good place to start.

Monitor SSL Certificate Expiry with Python and GitHub Actions

Stephano kambeta — Mon, 05 Oct 2026 10:00:00 +0000

A website that worked fine yesterday suddenly shows a big red warning today: "Your connection is not private." The site itself is fine. Only the SSL certificate ran out.

Most visitors won't click past that screen. They'll assume something is wrong and leave.

This usually happens for a boring reason. Auto-renewal was set up once, then a hosting move, a changed DNS record or a forgotten payment quietly broke it. Nobody noticed until the certificate expired.

This guide builds a small check that runs every day and warns you weeks before it happens. It uses one short Python script and GitHub Actions, and it's free.

Why this matters more now

SSL certificates are getting shorter-lived. Since March 15, 2026, publicly trusted certificates can last at most 200 days, down from 398. That drops to 100 days in March 2027 and 47 days in March 2029.

Shorter lifetimes mean more renewals. The first certificates issued under the 200-day limit are reaching their end around now.

If your renewals are automatic, this is mostly fine. But automatic only works while it keeps working, and that's what the check is for.

What you need

One or more websites served over HTTPS
A GitHub repository for the script. A new, empty one is fine

The script uses only what Python already includes, so there's nothing to install.

Step 1: Add the script

Create a file called check_ssl.py in your repository:

import os
import socket
import ssl
import sys
from datetime import datetime, timezone

DOMAINS = os.environ["DOMAINS"].split(",")   # for example: example.com,shop.example.com
WARN_DAYS = int(os.environ.get("WARN_DAYS", "21"))


def days_left(domain):
    context = ssl.create_default_context()
    with socket.create_connection((domain, 443), timeout=10) as sock:
        with context.wrap_socket(sock, server_hostname=domain) as tls:
            cert = tls.getpeercert()
    expires = datetime.fromtimestamp(ssl.cert_time_to_seconds(cert["notAfter"]), timezone.utc)
    return (expires - datetime.now(timezone.utc)).days


problems = []
for domain in (d.strip() for d in DOMAINS):
    try:
        left = days_left(domain)
    except Exception as error:  # expired, wrong name, site down...
        problems.append(f"{domain}: could not check the certificate ({error})")
        continue
    print(f"{domain}: {left} days left")
    if left < WARN_DAYS:
        problems.append(f"{domain}: certificate expires in {left} days")

if problems:
    print("\nProblems found:")
    print("\n".join(f"- {p}" for p in problems))
    sys.exit(1)

Here's how it works:

It connects to each site on port 443, the normal port for HTTPS.
It reads the expiry date from the certificate the site presents.
It counts the days left.
If any site has fewer days than the limit, or the certificate can't be checked at all, the script ends with an error.

That last part matters. When a script exits with an error, GitHub marks the run as failed, and that's what triggers your alert.

The check also catches certificates that are already expired or don't match the site name. In those cases the connection itself fails, and the script reports the reason.

Step 2: Add the workflow

Create .github/workflows/ssl-check.yml:

name: SSL certificate check

on:
  schedule:
    - cron: '41 5 * * *'   # every day at 05:41 UTC
  workflow_dispatch:        # adds a "Run workflow" button for testing

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Check certificates
        env:
          DOMAINS: example.com,www.example.com   # change this
          WARN_DAYS: '21'
        run: python3 check_ssl.py

Change DOMAINS to your own sites, separated by commas. List every hostname you use, including subdomains. A certificate for example.com doesn't tell you anything about shop.example.com.

Two small choices are worth noting:

The odd start time. 41 5 avoids the top of the hour, when GitHub is busiest and scheduled runs are more likely to be delayed.
The timeout. If a site hangs, the job stops after 5 minutes instead of running for hours.

A run like this takes a few seconds, but GitHub rounds each job up to a full minute. Running it daily uses about 30 minutes a month. That's nothing on a public repository, and a small part of the free allowance on a private one.

Step 3: Get alerted

By default, GitHub sends an email when a scheduled workflow fails. It goes to the person who last edited the schedule in the workflow file, as long as your notification settings allow it. Check your GitHub notification settings for Actions to be sure.

That may be all you need. If you'd like the alert somewhere you'll see it faster, add a message to a Discord channel. Put this step at the end of the job:

      - name: Send alert
        if: failure()
        env:
          WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK }}
        run: |
          curl -sS -X POST -H "Content-Type: application/json" \
            -d '{"content": "SSL certificate check failed. Open the workflow run for details."}' \
            "$WEBHOOK_URL"

Add your Discord webhook address as a repository secret named DISCORD_WEBHOOK. Never paste it into the workflow file, because anyone who has the address can post to your channel.

If webhooks are new to you, I wrote a beginner guide to how webhooks work.

Step 4: Test it

Go to the Actions tab in your repository, choose "SSL certificate check" and click "Run workflow". You should see a green check and a line for each site, like example.com: 63 days left.

To see an alert, change WARN_DAYS to 999 and run it again. Every site will count as "too close to expiring," the run will fail, and you'll get your email. Change it back to 21 afterwards.

Choosing the warning window

WARN_DAYS sets how early you want to be told.

Many automatic renewal setups start renewing a few weeks before the certificate expires. If you set the warning to 21 days, an alert usually means renewal should have happened by now and didn't. That's the useful signal.

If you renew by hand, use a longer window, like 30 days, so you have time to act.

What to do when the alert arrives

Don't panic. Weeks of warning is the point.

Check whether your hosting provider or certificate tool renews automatically, and whether it reported an error.
Look for recent changes: a new host, changed DNS records, a moved domain, or a payment that failed.
Renew the certificate and run the workflow again to confirm.

A quick manual check

If you just want to look at one site right now, this command shows the expiry date:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

It's handy for a one-off look. The script is better for anything you want to keep an eye on.

What this check can't do

It only checks what you list. A forgotten subdomain isn't watched until you add it.
It only checks port 443. Mail servers and other services use their own certificates.
It doesn't fix anything. It tells you a problem is coming, and you still have to renew the certificate.
It only sees what the server shows. If you use a service that serves different certificates to different visitors, you may see only one of them.

Will it keep running?

There's a catch that's easy to miss. In a public repository, GitHub switches off scheduled workflows after 60 days without any repository activity. A monitor that quietly stops is worse than none, because you think you're covered.

Put a reminder in your calendar or glance at the Actions tab now and then. I go into this more in how to monitor your automations when something breaks.

Quick answers

How long does an SSL certificate last?
Public certificates can now last at most 200 days. That limit falls to 100 days in March 2027 and 47 days in March 2029. Free authorities like Let's Encrypt already issue shorter ones.

What happens when a certificate expires?
Browsers show a full-page security warning. Most visitors leave, and some tools and apps refuse to connect at all.

How often should I check?
Once a day is plenty. A certificate doesn't go from healthy to expired in an hour.

Can this check a site that isn't mine?
Yes. It only opens a normal HTTPS connection, the same as a browser does. It's still a good idea to keep the list short and to your own sites.

The short version

An expired certificate is one of the most avoidable outages there is. It doesn't come as a surprise. The date has been printed on the certificate the whole time.

A daily check turns it into a routine warning weeks ahead. If you want a check for the site itself, my Python uptime monitor guide pairs well with this one.

You can find more practical automation guides on Procwire.

Build a Free Broken Link Checker with GitHub Actions

Stephano kambeta — Sun, 04 Oct 2026 10:00:00 +0000

A tutorial you wrote last year links to a company's documentation page. Since then, the company redesigned its site, the page moved, and the link now leads to a "404 Not Found."

Nobody tells you. Readers just click, hit a dead end, and leave.

Old posts are where this piles up. The more you publish, the harder it gets to remember what you linked to. Checking every link by hand doesn't scale, but a small script can do it for you every week.

This guide builds one. It reads your sitemap, checks every link on every page, and opens a GitHub issue when something is broken. When the links are fixed, it closes the issue on its own. It costs nothing and needs nothing to install.

What you need

A website with a sitemap.xml file (most blogs and site builders create one)
A GitHub repository to hold the script. It can be a new, empty one
Issues turned on in that repository (Settings, then Features)

You don't need to install any Python packages. The script only uses what Python already includes.

Step 1: Add the script

Create a file called check_links.py in your repository and paste this in:

"""Weekly broken link checker.

Reads your sitemap, opens every page, and checks every link on it.
If it finds broken links, it writes a short report to report.md.
Needs nothing but Python, so there is nothing to install.
"""
import os
import urllib.error
import urllib.request
import xml.etree.ElementTree as ET
from concurrent.futures import ThreadPoolExecutor
from datetime import date
from html.parser import HTMLParser
from urllib.parse import urldefrag, urljoin

SITEMAP_URL = os.environ["SITEMAP_URL"]
HEADERS = {"User-Agent": "Mozilla/5.0 (compatible; LinkChecker/1.0)"}
TIMEOUT = 15

# Many sites use these codes to turn away bots, even when the page is fine.
# We can't tell if the link is really broken, so we don't report it.
NOT_SURE = {401, 403, 429, 999}


def open_url(url, method="GET"):
    request = urllib.request.Request(url, headers=HEADERS, method=method)
    return urllib.request.urlopen(request, timeout=TIMEOUT)


class LinkParser(HTMLParser):
    """Collects the href of every <a> tag on a page."""

    def __init__(self):
        super().__init__()
        self.links = []

    def handle_starttag(self, tag, attrs):
        href = dict(attrs).get("href")
        if tag == "a" and href:
            self.links.append(href)


def get_pages():
    with open_url(SITEMAP_URL) as response:
        root = ET.fromstring(response.read())
    return [el.text.strip() for el in root.iter() if el.tag.endswith("}loc")]


def get_links(page):
    """Return the absolute http(s) links found on one page."""
    try:
        with open_url(page) as response:
            html = response.read(3_000_000).decode("utf-8", errors="replace")
    except Exception:
        return []  # the page itself gets reported when we check it below
    parser = LinkParser()
    parser.feed(html)
    links = set()
    for href in parser.links:
        url, _ = urldefrag(urljoin(page, href))
        if url.startswith(("http://", "https://")):
            links.add(url)
    return links


def check_link(url):
    """Return None if the link works, or a short reason if it doesn't."""
    reason = None
    for _ in range(2):  # one retry, in case of a temporary hiccup
        try:
            open_url(url, "HEAD").close()
            return None
        except Exception:
            pass  # some servers reject HEAD requests, so try a normal GET
        try:
            open_url(url, "GET").close()
            return None
        except urllib.error.HTTPError as error:
            if error.code in NOT_SURE:
                return None
            reason = f"HTTP {error.code}"
            if error.code < 500:
                return reason  # a 404 won't fix itself in five seconds
        except Exception as error:
            reason = f"Could not connect ({type(error).__name__})"
    return reason


def main():
    if os.path.exists("report.md"):
        os.remove("report.md")

    pages = get_pages()
    print(f"Found {len(pages)} pages in the sitemap")

    # Map each link to the pages it appears on
    found_on = {page: {"the sitemap"} for page in pages}
    with ThreadPoolExecutor(max_workers=5) as pool:
        for page, links in zip(pages, pool.map(get_links, pages)):
            for link in links:
                found_on.setdefault(link, set()).add(page)

    urls = list(found_on)
    print(f"Checking {len(urls)} links...")
    with ThreadPoolExecutor(max_workers=8) as pool:
        results = list(pool.map(check_link, urls))

    broken = [(url, reason) for url, reason in zip(urls, results) if reason]
    print(f"Broken links: {len(broken)}")
    if not broken:
        return

    lines = [
        f"Checked {len(pages)} pages and {len(urls)} links on {date.today()}.",
        f"Found {len(broken)} broken link(s).",
        "",
    ]
    for url, reason in sorted(broken):
        lines.append(f"### {url}")
        lines.append(f"Problem: {reason}")
        lines.append("Found on:")
        lines += [f"- {source}" for source in sorted(found_on[url])]
        lines.append("")
    with open("report.md", "w") as report:
        report.write("\n".join(lines))


main()

Here's what it does, in plain terms:

It reads your sitemap to get a list of pages.
It opens each page and collects every link.
It checks each link once, even if it appears on ten pages.
If any are broken, it writes a report that lists each broken link and where it appears.

Your own pages get checked too. That means a page in your sitemap that no longer loads shows up in the report.

Step 2: Add the workflow

Create the file .github/workflows/link-check.yml:

name: Weekly link check

on:
  schedule:
    - cron: '23 6 * * 1'   # Mondays at 06:23 UTC
  workflow_dispatch:        # adds a "Run workflow" button for testing

permissions:
  contents: read
  issues: write

jobs:
  check-links:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4   # use the latest major version

      - name: Check links
        env:
          SITEMAP_URL: https://example.com/sitemap.xml   # change this
        run: python3 check_links.py

      - name: Open, update or close the issue
        env:
          GH_TOKEN: ${{ github.token }}
          GH_REPO: ${{ github.repository }}
        run: |
          gh label create broken-links --color D93F0B \
            --description "Found by the weekly link check" --force
          existing=$(gh issue list --label broken-links --state open \
            --json number --jq '.[0].number // empty')

          if [ -f report.md ]; then
            if [ -n "$existing" ]; then
              gh issue edit "$existing" --body-file report.md
            else
              gh issue create --title "Broken links found" \
                --label broken-links --body-file report.md
            fi
          elif [ -n "$existing" ]; then
            gh issue close "$existing" --comment "No broken links found this week."
          fi

Change SITEMAP_URL to your own sitemap address. That's the only setting you need to touch.

A few choices in there are worth explaining:

An odd start time. 23 6 avoids the top of the hour, when GitHub is busiest and scheduled runs are most likely to be delayed.
A timeout. If something hangs, the job stops after 15 minutes instead of running for hours.
Limited permissions. The workflow can read your code and manage issues, and nothing else.
One issue at a time. If there's already an open issue, the workflow updates it instead of creating a new one every week. When a week comes back clean, it closes the issue.

Step 3: Test it

Don't wait until Monday. Go to the Actions tab in your repository, choose "Weekly link check", and click "Run workflow".

To see the issue appear, add a link you know is broken to one of your pages, wait for your site to update, and run it again. Then fix the link and run it once more. The issue should close itself.

What counts as "broken"?

The script reports a link when:

The page returns a "not found" or similar error, like 404 or 410
The server returns a server error, like 500, even after a retry
The address can't be reached at all, for example because the domain no longer exists

It doesn't report links that return 401, 403 or 429. Many sites, LinkedIn among them, block automated visitors even when the page works fine for people. Reporting those would fill your issue with false alarms, so the script skips them. The tradeoff is that a link that's really broken behind one of those codes goes unnoticed.

Redirects are followed, so an old link that lands on a working page counts as fine.

Tweaks you might want

Ignore certain sites. If a site keeps causing false alarms, skip it. In get_links, change the if line so it also checks a list of domains to ignore:

IGNORE = ("linkedin.com", "twitter.com")   # add near the top

# ...and in get_links:
if url.startswith(("http://", "https://")) and not any(d in url for d in IGNORE):

Run monthly instead of weekly. For a small blog, once a month is often enough. Change the cron line to something like '23 6 1 * *'.

Be gentler on other sites. The script checks a handful of links at a time. If you have a huge site, lower max_workers so you don't send too many requests at once.

What it can't catch

It's a simple tool, and it has limits:

It only checks links in <a> tags. Images, scripts and stylesheets aren't checked.
It doesn't run JavaScript, so links that only appear after a page loads in a browser are missed.
It doesn't understand a sitemap index (a sitemap that lists other sitemaps). If yours is one, point it at each sitemap separately.
Some sites show a "page not found" message but still return a normal success code. The script can't tell.

Will it stay running?

This is worth a thought, because the checker can fail quietly too.

In a public repository, GitHub switches off scheduled workflows after 60 days without any repository activity. If the checker repo is one you never touch, it may stop running without telling you. Put a reminder in your calendar, or glance at the Actions tab now and then.

The same idea applies to any automation you set and forget. I wrote about it in how to monitor your automations when something breaks.

Is this worth automating?

For most blogs, yes. It's a good example of a task that suits automation:

It's repetitive and boring
It's easy to check that it worked
A mistake costs very little, since the worst case is a false alarm in an issue

If you want a way to judge other tasks, I wrote about when not to automate.

Quick answers

How often should I check for broken links?
Weekly is fine for an active blog. Monthly works for a small one that rarely changes.

Does this cost anything?
No. A weekly run takes a few minutes a month. Public repositories don't use up any free minutes, and private repositories only use a tiny part of the monthly allowance.

Can I check a site that isn't mine?
It works for any site with a sitemap, but be considerate. Don't run it often against other people's sites.

Why did it report a link that works in my browser?
Some servers treat scripts differently from browsers. Open the link yourself first. If it works, add that domain to the ignore list.

The short version

Broken links don't break anything loudly. They just make your older posts a little less useful, one dead end at a time.

A weekly check turns that into a short list of things to fix. If you build it once, you can leave it alone.

If you want more practical guides like this, you can find them on Procwire. I also wrote a Python uptime monitor guide that pairs well with this one.

GitHub Actions Secrets: 8 Common Mistakes and Fixes

Stephano kambeta — Sat, 03 Oct 2026 10:00:00 +0000

You build a small automation that posts to Discord when your website goes down. To make it work, you paste the webhook URL into your script. It works on the first try, so you commit it and move on.

Months later, you make the repo public to share it. Now anyone can read that URL, and anyone can post to your Discord channel.

Secrets are one of those things that feel like a small detail until they aren't. Here are eight common ways they leak in GitHub Actions, and how to avoid each one.

What counts as a secret?

Anything that gives access to something. That includes API keys, passwords, tokens and webhook URLs.

If you're not sure whether something is a secret, ask: what could someone do if they had this? If the answer is "post as me," "use my account" or "spend my quota," treat it as a secret.

(If API keys and webhooks are still a bit fuzzy, I've written a beginner guide to what an API is and one on how webhooks work.)

1. Hardcoding the secret in your files

This is the classic. The key sits right in your script or workflow file, and it stays in your git history even if you delete it later.

Store it as a repository secret instead. In your repo, open Settings, then Secrets and variables, then Actions, and add it there. Then read it in your workflow:

- name: Send alert
  env:
    WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK }}
  run: python alert.py

Your script reads WEBHOOK_URL from the environment, so the real value never appears in the code.

Passing it through env is also cleaner than pasting ${{ secrets.X }} directly into a command. It avoids quoting problems and keeps the value out of the command text.

2. Printing it in the logs

You're debugging. Something isn't working, so you add a line to check the value:

run: echo "Token is $API_TOKEN"

GitHub tries to hide secrets in logs, but that only helps if the secret matches exactly. Debug commands that print all environment variables can expose more than you meant to.

Remove debug lines before you commit. If you need to check that a secret is set, print whether it's empty, not what it contains.

3. Trusting log masking to catch everything

GitHub hides secret values it recognizes in your logs. But GitHub's own documentation says automatic redaction isn't guaranteed, because a value can be changed in many ways before it's printed.

For example, if your script encodes the secret or cuts it into pieces, the result may not match the original, and it may show up in plain text.

Two habits help here:

Store each secret as its own single value. Don't store a whole block of JSON or YAML as one secret, because redaction can miss parts of it.
If your workflow builds a sensitive value on its own, tell GitHub to hide it:

- run: echo "::add-mask::$CUSTOMER_ID"

4. Using a key with more power than the job needs

Say your automation only needs to post messages. If you give it a key that can also delete things and change settings, a leak becomes far more damaging.

Use the smallest permission that works, and use a separate key for each project so you can cancel one without breaking the rest.

Where the service allows it, use a restricted key instead of your main login. That's why bots for Bluesky use an app password, not the account password. I covered this in my Bluesky automation bot guide.

Also remember that anyone with write access to your repository can read its secrets. Think before you add collaborators.

5. Leaving GITHUB_TOKEN with too much access

Every workflow run gets a built-in token called GITHUB_TOKEN. It lets the workflow talk to your repository, and it can have more permissions than the job needs.

GitHub recommends making read-only access the default and adding more only where a job needs it. You can set this at the top of your workflow file:

permissions:
  contents: read

If one job needs to write something, give that job the extra permission and leave the rest alone.

6. Running risky workflows from pull requests

This one matters most if your repo is public or forkable.

On a normal pull_request trigger, workflows from forks don't get your secrets. That's a good default. The trouble starts when people switch to pull_request_target, which does run with access to secrets.

GitHub's advice is to avoid pull_request_target unless you need it. If you do use it, don't check out and run code from an untrusted pull request. A stranger's code running with your secrets is the situation to avoid.

For a small personal automation, the simplest option is not to trigger workflows from outside pull requests at all.

7. Pasting untrusted text straight into a command

Some workflows react to issues or pull requests and use their titles or descriptions in a script:

- run: echo "New issue: ${{ github.event.issue.title }}"

The problem is that anyone can write an issue title. If a title contains shell commands, they may end up running on your runner, with access to your secrets.

The safer way is to put the value in an environment variable first:

- env:
    TITLE: ${{ github.event.issue.title }}
  run: echo "New issue: $TITLE"

Now the title is treated as plain text, not as part of the command.

8. Using third-party actions without a second look

When you write uses: someone/some-action@v1, you're running someone else's code. If you pass it a secret, it can use that secret.

A few habits help:

Prefer actions from GitHub itself or from well-known, maintained projects.
Read what the action does before you give it a secret.
Pin it to a full commit SHA instead of a version tag. A tag can be moved to different code later, but a commit can't.

- uses: some-owner/some-action@<full-commit-sha>  # v1.2.3

Leave a comment with the version number so you remember what the SHA means.

What to do if a secret leaks

Act in this order.

Replace the secret first. Create a new key or token, put it in GitHub Secrets, and cancel the old one at the source. This is the step that actually protects you.
Delete the workflow logs that show the value, if it appeared in a log. GitHub's advice is to delete the log and rotate the secret.
Check for misuse. Look at the service's activity or usage page for anything you don't recognize.
Then clean up your repo, if the secret was committed. Removing it from history is good, but don't rely on it. Once something has been public, assume someone copied it.

Deleting the file or the commit is not enough on its own. The old key still works until you cancel it.

A quick checklist

Before you push a new workflow, run through this:

No secrets in the code or in workflow files
No debug lines that print secrets
Each secret is a single value, not a block of JSON
Each key has only the permissions it needs
permissions: contents: read is set unless the job needs more
No pull_request_target unless you really need it
Untrusted text goes through env, not straight into run
Third-party actions are trusted and pinned
Secret scanning and push protection are turned on in your repository's security settings

Quick answers

Are GitHub Actions secrets safe?
They're encrypted and hidden in logs, but they're only as safe as your workflow. Printing them, passing them to untrusted code, or giving collaborators write access can all expose them.

Can people see my secrets after I save them?
No. You can replace a secret but not read it back. However, anyone with write access to the repo can use it in a workflow.

Do forks get my secrets?
Not on a regular pull_request trigger. They can be exposed by workflows that run with more privileges, like pull_request_target, so use those carefully.

How often should I rotate secrets?
Whenever someone who had access leaves, whenever you suspect a leak, and every so often for keys that matter. Set a reminder so it doesn't depend on memory.

The short version

Most secret leaks aren't clever attacks. They're a debug line, a pasted key, or a key with more power than it needed.

Keep secrets out of your files, keep them out of your logs, and give each one only the access it needs. Do that, and you've covered most of the risk.

If you'd like more practical guides on small automations, you can find them on Procwire.

How to Stay Within GitHub Actions' Free Minutes

Stephano kambeta — Fri, 02 Oct 2026 10:00:00 +0000

You set up a small workflow to check your website every 5 minutes. It works well. Then, a few weeks later, GitHub tells you your free minutes are almost gone.

How did a tiny script use that much?

If you use GitHub Actions for small automations, this is worth understanding before it happens. The good news is that a few small changes can cut your usage a lot, and most of them take a couple of minutes.

Are GitHub Actions minutes actually free?

It depends on the type of repository.

Public repositories: standard GitHub-hosted runners are free, with no minute cap.
Private repositories: you get a monthly allowance based on your plan. The Free plan includes 2,000 minutes a month. After that, you pay per minute.

Two details catch people out:

Windows and macOS cost more. On private repos, a Windows minute counts as 2 and a macOS minute counts as 10. Stick to ubuntu-latest unless you really need something else.
Every job is rounded up. A job that runs for 20 seconds is billed as a full minute.

(Allowances and prices change from time to time, so check GitHub's billing page for the current numbers.)

Why small workflows use more minutes than you'd expect

Here's the rounding in practice. Say your job takes 20 seconds, so it's billed as 1 minute each time it runs.

Schedule	Runs per month	Minutes used per month
Every 5 minutes	8,640	8,640
Every 10 minutes	4,320	4,320
Every 15 minutes	2,880	2,880
Every 30 minutes	1,440	1,440
Every hour	720	720

Based on a 30-day month. Each run is billed as 1 minute.

Now compare that to 2,000 free minutes. On a private repo, a check every 5, 10 or 15 minutes uses up the allowance before the month is over. Every 30 minutes fits, with some room left.

If your repo is public, none of this costs you anything. But public also means anyone can read your workflow files and code. Keep passwords and API keys in GitHub Secrets, never in the files themselves.

1. Run less often

This is the biggest saver, and it costs nothing.

Ask yourself how quickly you'd really need to know. For a personal project, finding out about downtime within 30 minutes is often fine. For a daily report, once a day is plenty.

Going from every 5 minutes to every 30 cuts your usage by 6 times.

While you're editing the schedule, avoid the top of the hour. GitHub can delay scheduled runs when it's busy, and the start of each hour is the busiest time.

on:
  schedule:
    - cron: '17,47 * * * *'   # every 30 minutes, at :17 and :47

2. Set a timeout on every job

By default, a GitHub Actions job can run for up to 6 hours before GitHub stops it.

Picture a script that calls a website. The website hangs, your script waits, and the job sits there using minutes until the limit hits. On a private repo, one stuck run can use a big slice of your monthly allowance.

Add a timeout that matches what the job should take:

jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 5

If your script normally takes 30 seconds, 5 minutes is plenty. If it takes longer than that, something is wrong and you want it stopped.

3. Cache what you keep downloading

If your workflow installs the same packages on every run, you're paying for that download time each time.

Caching saves those packages between runs. For Python, it's one extra line:

- uses: actions/setup-python@v5   # use the latest major version
  with:
    python-version: '3.12'
    cache: pip

Treat the cache as a speed-up, not as storage. GitHub can remove old cache entries, so your workflow should still work when there's no cache.

4. Only run when something relevant changed

Some workflows run on every push, even when you only edited a README.

The paths filter tells GitHub to run the workflow only when certain files change:

on:
  push:
    paths:
      - 'src/**'
      - 'requirements.txt'

Now a typo fix in your docs doesn't start a test run.

5. Cancel runs you no longer need

Say you push three quick fixes in a row. Without any settings, GitHub runs the workflow for all three. Only the last one matters.

The concurrency setting cancels the older runs:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

This is great for workflows that run on pushes. Be careful with jobs where every run matters, like one that processes each order or sends a message. Cancelling those could skip work.

6. Keep the job count low

Each job is rounded up to a full minute and has its own setup time. Three small jobs that each take 15 seconds are billed as 3 minutes. One job with three steps might be billed as 1.

If the steps don't need to run on separate machines, put them in one job.

7. Check your usage before it becomes a problem

Look at the usage numbers in your GitHub account's billing settings. Once a month is enough. You'll see which workflow uses the most minutes, and it's usually one scheduled job that runs more often than it needs to.

It also helps to know what happens when you run out. On a private repo, your workflows can stop running or start costing money, depending on your billing settings. If a scheduled check simply stops, you may not notice right away, so it's worth setting up a way to be told when an automation breaks.

Quick answers

Is GitHub Actions free?
Yes for public repositories on standard runners. Private repositories get a monthly allowance, and the Free plan includes 2,000 minutes.

How can I check how many minutes I've used?
Open your account's billing settings and look at the Actions usage.

What uses the most minutes?
Usually a scheduled workflow that runs every few minutes, or a job that got stuck and ran until the timeout.

Do Windows and macOS runners use more minutes?
Yes, on private repositories. Windows counts double and macOS counts ten times.

When GitHub Actions stops being the cheapest option

For a few small checks and scripts, GitHub Actions is hard to beat. But if you need checks every minute, or a lot of frequent jobs on a private repo, the free allowance won't stretch that far.

At that point you can pay for extra minutes, run the job on a small server you already have, or use a tool built for that job. I compared the options for small teams in Zapier vs GitHub Actions.

The short version

Most free-minute problems come from three things: schedules that run too often, jobs that run longer than they should, and workflows that start when they don't need to.

Fix those, and a handful of small automations fits comfortably in the free allowance.

If you want to see this in a real project, my Python uptime monitor guide shows a check that runs on a schedule. You can find more practical automation guides on Procwire.

Why Your Scheduled GitHub Actions Workflow Runs Late (or Stops Running Entirely)

Stephano kambeta — Thu, 01 Oct 2026 10:00:00 +0000

You set up a workflow to run every morning. It worked for a week, then two weeks. Then one day you check the Actions tab and see the last run was a month ago.

No error. No email. It just stopped.

If you use GitHub Actions for small automations like reports, checks or posts, this can happen to you. The scheduler isn't broken. It just works differently from what most people expect.

"Every day at 9:00" is more of a suggestion

When you write a cron schedule in GitHub Actions, you're telling GitHub when you'd like the workflow to start. You're not guaranteeing it.

GitHub says scheduled runs can be delayed when a lot of workflows are running at once. The busiest time is the start of every hour. In bad cases, a queued run can be dropped completely.

If your workflow is set to 0 9 * * *, you're asking for the most crowded minute of the day. Try 17 9 * * * instead. The odd minute costs you nothing, and it makes a delay less likely.

The 60-day quiet period

This is the one that catches people.

In a public repository, GitHub automatically turns off scheduled workflows after 60 days without any repository activity. Your workflow file is still there and the cron line still looks fine, but it has been switched off.

Picture a small shop owner who sets up a Monday morning sales summary. The workflow works, so they leave the repo alone. Two months later the summaries stop, and nobody notices until someone asks where the numbers went.

To fix it, open the Actions tab and re-enable the workflow. Any new activity in the repo resets the clock. If your automation is the only thing in that repo, put a reminder in your calendar every couple of months.

A few other quiet reasons

Sometimes nothing is wrong with the schedule. The setup just doesn't match what GitHub expects.

Wrong branch. Scheduled workflows only run from the default branch. A workflow that only exists on a feature branch will never fire.
Forks. If you forked someone's project, scheduled workflows in your copy don't run until you enable them.
Time zones. Cron times are in UTC by default. "9:00" may not be 9:00 where you are.
The person who last edited it left. If that person is removed from the repository, the scheduled workflow can be disabled. Changing the cron line with write access turns it back on.
Too frequent. The shortest interval is every 5 minutes. Anything faster won't work.

Why this is worse than it sounds

A workflow that fails loudly is easy to deal with. You get a red mark, you look at it, you fix it.

A workflow that stops running leaves nothing to look at. There's no failed run, because there's no run at all.

Say you built a free uptime check that pings your website every 10 minutes. If the schedule quietly stops, you have no monitoring. You'd find out when a customer tells you your site has been down. (If you want to build one, I wrote a Python uptime monitor guide.)

What you can do about it

You don't need anything complicated. A few habits cover most of it.

Pick odd minutes. Avoid :00 and :30 when you can.

Make the job forgiving. If a run is late or skipped, the next one should catch up. A script that says "process everything since the last successful run" is safer than one that assumes it runs exactly on time.

Watch for the absence of a run. This is the important one. Add a last step that sends a small "I finished" ping to a monitoring service, and set that service to alert you when a ping doesn't show up. Now silence sets off the alert.

I go into this more in how to monitor your automations when something breaks.

Check once in a while. Open the Actions tab once a month and look at the run history. It takes two minutes.

When GitHub's scheduler isn't the right tool

If a task has to run at an exact time, like a payment cutoff or a message that must go out at a specific minute, a free scheduler on shared infrastructure may not be enough. That isn't a flaw. GitHub built it for convenience, not precision.

For a daily report, a content post or a website check, a few minutes of drift usually doesn't matter. Just make sure you'd notice if it stopped.

The short version

A scheduled workflow is convenient, but it isn't guaranteed. It can run late, get dropped, or switch itself off.

So ask yourself: if this stopped tomorrow, how long would it take you to find out?

If the answer is "a while," add the heartbeat check first. You can find more practical automation guides on Procwire.

Building a Free Uptime Monitor in Under 30 Minutes (No Paid Tools)

Stephano kambeta — Tue, 22 Sep 2026 12:52:46 +0000

Uptime monitoring tools usually charge based on how many sites you're checking and how often. For one or two personal projects, that's a lot of money for something that's really just "ping this URL, tell me if it's down."

Here's a version that costs nothing and takes under half an hour to set up, using Python and GitHub Actions.

What it actually needs to do

Check if a site responds, on a schedule. If it doesn't respond, or the response code isn't in the 200 range, send an alert somewhere you'll actually see it — Discord, Slack, or Telegram all work fine with a webhook.

That's the entire feature set. No dashboard, no historical uptime percentage, no status page. Just a check and an alert.

The script

The core of it is a short Python script: send a request to the URL, check the status code, and if it fails, send a message to a webhook URL for whichever chat platform you're using. Discord, Slack, and Telegram all accept a simple POST request with a JSON body, so the alerting part is a few lines regardless of which one you pick.

The schedule

This is where GitHub Actions does the actual work. A schedule trigger with a cron expression runs the script automatically — every 5, 10, or 15 minutes, depending on how tight you want the check interval. No server, no cron job on a machine you have to keep running, no hosting cost.

The webhook URL and any other secrets go into the repo's encrypted secrets, not into the script itself, so nothing sensitive ends up committed to the repository.

Where the 30 minutes goes

Most of the time is the workflow file, not the Python. Getting the YAML syntax right for the schedule trigger, making sure the secret gets passed into the script as an environment variable, and testing that a failed check actually triggers the alert — that's the bulk of it. The Python itself is short enough to write in a few minutes once you know what the request and webhook call need to look like.

If you'd rather see the whole thing built out step by step instead of piecing it together from this summary, I wrote the full version with the actual code in this Python uptime monitor guide.

Skipping the build entirely

If you don't need to build this yourself, there's a ready-to-use template with the script and workflow already set up — you plug in the URL and the webhook, and it's running.

Where this approach has real limits

This isn't a replacement for a proper monitoring tool if you need historical uptime data, multi-region checks, or alerting that escalates through multiple channels if the first one doesn't get acknowledged. It's also only as reliable as GitHub Actions' scheduler, which can run a few minutes late under load — fine for a personal project, not something to rely on for anything with a strict SLA.

For checking that your side project's site is actually up, though, it does the whole job for free.

More free, no-paid-tools build guides like this over at Procwire.

The 4-Question Test for 'Is This Actually an AI Agent?'

Stephano kambeta — Tue, 22 Sep 2026 12:50:28 +0000

"Agent" gets used loosely enough now that it's worth having a quick way to check if something actually is one, or if it's just a chatbot or a script wearing the label. Here's a four-question test that usually settles it.

1. Does it take action, or just suggest one?

A tool that tells you what to do isn't the same as a tool that does it. If the system writes a draft and waits for you to send it, that's an assistant. If it sends the email itself as part of finishing the task, that's a real action — the kind of thing the actual line between an assistant and an agent comes down to.

2. Does it decide what to do next, or wait for you to tell it?

This is the core of it. A script runs the same steps every time, in the same order, no matter what it finds along the way. An agent looks at what just happened and picks its next step based on that — check the account, then decide whether to escalate or resolve, based on what it found.

If every step is predetermined regardless of the input, you're closer to a fixed workflow — which might genuinely be the better fit, depending on how much the task actually varies.

3. Does it use tools on its own, or only when you trigger them?

An agent typically has access to a set of tools — search, a database, an API, a calendar — and chooses which one to call based on the task, without you specifying which one to use each time. If a human is picking the tool and the "agent" just executes that one action, the decision-making is happening outside the system, not inside it.

4. Does it remember and use information from earlier steps to change its next move?

This one trips people up because "remembering" the current conversation isn't the same as having memory that changes future behavior. If a system used something it learned three steps ago to make a different decision now, that's real state being carried forward. If it's just re-reading the same conversation transcript every time without acting on anything from it, that's not the same thing. The distinction between short-term context and actual memory is where a lot of "agents" quietly fall short.

Scoring it

Four yeses, and you're building or using a genuine agent — something that plans, decides, and acts with real autonomy over the process. Mostly no's usually means assistant, chatbot, or a fixed automation, and none of those are worse. They're just a different, often simpler and more predictable tool for a task that doesn't need judgment calls.

The test isn't really about the label. It's a fast way to check whether you're about to build something more complex than the task actually requires — or, just as often, less capable than the task actually needs.

More on how these systems actually differ over at Procwire.

I Automated My Bluesky Presence for $0 — Full Build Walkthrough

Stephano kambeta — Tue, 22 Sep 2026 12:46:39 +0000

Keeping a Bluesky account active takes more consistency than most people have time for. You need something to post regularly, and ideally something that doesn't feel like the same three posts on repeat. Most tools that do this charge a monthly fee per account.

I built a version that costs nothing to run, using GitHub Actions and an AI model to generate the posts. Here's the actual build.

What it needed to do

Three things: generate a post on a schedule, keep it on-topic and in a consistent voice, and publish it to Bluesky without me touching anything. Optionally, react to some activity — likes, replies, follows — based on simple rules, without needing a server running all the time.

Why GitHub Actions instead of a server

Bluesky posting tools are usually SaaS products because they assume you need something always running — checking for replies, posting on a timer, handling retries. But a scheduled workflow does the "post on a timer" part for free, and you don't need a server sitting idle the rest of the time waiting for a cron job to fire.

GitHub Actions has a schedule trigger that runs on a cron expression, generous free minutes for this kind of light, infrequent job, and no infrastructure to manage. That's most of what a paid scheduler is charging you for.

The actual pieces

The workflow itself is a YAML file with a schedule trigger and a job that runs a script. The script does three things: builds a prompt from the topics and personality you've set, calls an LLM (I used Gemini) to generate the post text, and calls the Bluesky API to publish it. Secrets — the Bluesky login and the Gemini API key — live in GitHub's encrypted repo secrets, not in the code.

The part that took the most iteration wasn't the posting — it was the prompt. Getting consistent tone and topic focus out of the model, without it drifting into generic filler after a few dozen posts, took some trial and error on how specific the prompt needed to be.

I wrote the complete version of this, including the actual workflow file and prompt structure, in this Bluesky automation build guide. If you'd rather not build it from scratch, there's a free, ready-to-use version with the topics, personality, and schedule left configurable, and a more advanced paid version that adds AI-generated images and can reply to comments, like, and follow based on keywords — with built-in limits so it doesn't overdo it.

Where the "free" part has limits

GitHub Actions' free tier is generous for something posting a few times a day, but it's not unlimited, and running it far more frequently — or across a lot of accounts — will eventually hit usage limits or need a paid GitHub plan. The Gemini API also has its own free tier with rate limits, so a very high posting frequency could bump into that before GitHub Actions becomes the bottleneck.

For a normal posting cadence — a handful of posts a day — none of this matters. It only becomes a real constraint if you're trying to run this at a scale closer to a full social media operation than a personal or small-project account.

What actually changed

The account posts consistently now without me remembering to. That's the whole win. It's not a growth hack — it just removes the part where consistency depends on me actually opening the app that day.

Full write-up and code for this build: Build a Bluesky Automation Bot for Free with GitHub Actions and Gemini AI.

More free build walkthroughs like this over at Procwire.