How can I run scheduled URL availability checks with GitHub Actions?

[edwardjames12]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Hi everyone,

I'm working on a small web-service monitoring workflow and I'm trying to understand the best way to run periodic URL availability checks with GitHub Actions.

The basic workflow I have in mind is:

1. Start an Actions runner.
2. Send an HTTP request to a public URL.
3. Check the response status and response time.
4. Save the result as an Actions artifact or workflow summary.
5. Run the check periodically with a scheduled workflow.

One of the services I'm testing is fdown.media, so I'm using it as an example endpoint rather than as an Actions-related product.

I'm particularly interested in the runner side of this. If using Actions Runner Controller, would you recommend creating a short-lived runner for each monitoring job, or keeping a runner available for recurring checks?

I'm also interested in best practices for:

• handling request timeouts;
• avoiding unnecessary runner usage;
• storing only the monitoring results needed for debugging;
• preventing credentials or other sensitive information from appearing in workflow logs.

For a lightweight scheduled monitoring task like this, what runner setup would you recommend?

[kurupdevs]

For this, a plain GitHub-hosted ubuntu runner is plenty. Use the schedule trigger with a cron expression and run curl with --fail and --max-time 20, so timeouts fail cleanly instead of hanging. Write a short summary to the job summary with $GITHUB_STEP_SUMMARY and upload only a small JSON artifact rather than full logs, which keeps storage low. Keep any tokens in secrets and mask them with ::add-mask:: so they never appear in logs. If you already run ARC, a short-lived ephemeral runner per check is the right pattern; keeping one warm for a check this light just wastes resources.

[beenish-majeed]

Hi @edwardjames12, for a check this light, I'd use a plain GitHub-hosted ubuntu-latest runner and skip ARC unless you already have a reason to run Kubernetes-managed runners. If you do already run ARC, an ephemeral runner per check is a good fit. A warm runner sitting idle between checks isn't useful for a job this short.
Here's a complete example. Replace URL with the endpoint you want to check (fdown.media is just the example from your post):

name: URL check

on:
  schedule:
    - cron: "*/15 * * * *"
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: url-check
  cancel-in-progress: false

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

    steps:
      - name: Check URL
        env:
          URL: https://fdown.media
        run: |
          curl_exit=0
          out=$(curl -sS -L -o /dev/null \
            --connect-timeout 10 \
            --max-time 20 \
            -w '%{http_code} %{time_total}' \
            "$URL") || curl_exit=$?

          if [ "$curl_exit" -ne 0 ]; then
            code=0
            secs=0
          else
            code=${out%% *}
            secs=${out##* }
          fi

          echo "{\"url\":\"$URL\",\"status\":$code,\"seconds\":$secs,\"curl_exit\":$curl_exit,\"checked_at\":\"$(date -u +%FT%TZ)\"}" > result.json

          echo "| $URL | $code | ${secs}s | curl exit $curl_exit |" >> "$GITHUB_STEP_SUMMARY"

          [ "$curl_exit" -eq 0 ] && [[ "$code" =~ ^2 ]] || exit 1

      - name: Save result
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: url-check-result
          path: result.json
          retention-days: 7

How this maps to your questions:

• Timeouts: --connect-timeout limits connection setup, --max-time 20 limits the request, and timeout-minutes: 3 caps the job itself.
• Failure types: a curl failure (DNS error, timeout, refused connection, etc.) is recorded separately from the HTTP status, so you can distinguish "the server responded with an error" from "the request couldn't reach it."
• Redirects: -L follows redirects, so a 301/302 that eventually reaches 2xx counts as success. Remove -L if redirects should be treated as failures.
• Response time: %{time_total} records the request duration, and the job summary gives you a quick readable result.
• Runner usage: the job is short-lived, and the concurrency group prevents overlapping checks from piling up.
• Storage: the artifact is one small JSON file retained for 7 days, and if: always() preserves it even when the check fails.
• Retries: I left retries out so a failed check is immediately visible. If you add one, I'd keep it limited so retries don't hide a real outage.
• Secrets: don't put tokens in URLs, since URLs can appear in logs. Pass credentials through environment variables backed by GitHub Secrets, and don't print them or use verbose curl output. GitHub masks repository secrets in logs; ::add-mask:: is mainly useful for sensitive values generated during the workflow.

One other distinction is important: a 2xx response only tells you that the endpoint responded successfully. If you're actually monitoring service health, consider checking an expected response body or enforcing a latency threshold as well.
For low-stakes or hobby monitoring, this approach is reasonable. If you eventually need guaranteed monitoring, richer alerting, or very frequent checks, a dedicated monitoring service is a better fit because scheduled Actions runs aren't designed to provide uptime-monitoring guarantees.
And since this will hit a live endpoint every 15 minutes, I'd keep the polling interval reasonable and make sure you have permission to monitor the service.

[Jyotir2004]

For a lightweight scheduled URL-monitoring workflow, the main design question is whether you actually need ARC. For many simple checks, a GitHub-hosted runner is sufficient; ARC becomes more useful when you need Kubernetes-based, autoscaled, ephemeral self-hosted runners.

Recommended setup

For your use case, I'd start with a GitHub-hosted runner:

name: URL Monitor

on:
schedule:
- cron: "*/10 * * * *"
workflow_dispatch:

jobs:
monitor:
runs-on: ubuntu-latest
timeout-minutes: 2

steps:
  - name: Check URL
    run: |
      URL="https://example.com"

      curl \
        --fail \
        --silent \
        --show-error \
        --location \
        --max-time 20 \
        --output /dev/null \
        --write-out "status=%{http_code} time=%{time_total}s\n" \
        "$URL"

For a small monitoring job, keeping a self-hosted runner permanently available generally isn't necessary. With ARC, an ephemeral runner per job is usually the better isolation model when you do need self-hosted infrastructure.

If you use ARC

A reasonable architecture is:

Scheduled workflow
↓
GitHub Actions
↓
ARC Runner Scale Set
↓
Ephemeral runner
↓
HTTP check
↓
Result / summary
↓
Runner removed

This gives each monitoring execution a clean environment and avoids maintaining an idle runner between checks.

Practical recommendations

Timeouts

Use several layers rather than allowing curl to run indefinitely:

curl --connect-timeout 5 --max-time 20 ...

and also set a job-level timeout:

timeout-minutes: 2

Results

For a simple monitor, you probably don't need to retain full logs as artifacts every time. A workflow summary containing:

timestamp
URL
HTTP status
response time
success/failure

is usually enough.

Keep artifacts for cases where you actually need historical/debugging information.

Credentials

Don't put tokens directly into:

run: echo "$TOKEN"

Use GitHub Actions secrets:

env:
API_TOKEN: ${{ secrets.API_TOKEN }}

and avoid printing the environment or complete request headers.

Important: if the endpoint itself is public, you don't need credentials just to perform an availability check.

One additional consideration

If the purpose is simply continuous website monitoring, GitHub Actions isn't necessarily the most natural monitoring infrastructure. Scheduled workflows can be delayed, particularly during periods of Actions load, so they shouldn't be treated as a precise uptime-monitoring clock.

For example, */10 * * * * means request the job approximately every ten minutes, not necessarily perform the HTTP request exactly every ten minutes.

For lightweight periodic checks, GitHub Actions is perfectly reasonable for development/testing. For strict uptime monitoring and alerting, a dedicated monitoring service or continuously running monitoring system is generally more appropriate.

So, for your stated workload:

GitHub-hosted ubuntu-latest → simplest choice.
ARC + ephemeral runners → useful if you specifically need Kubernetes/self-hosted infrastructure.
Persistent ARC runner → generally unnecessary for this short-lived monitoring job.

[labagent24]

I actually went through this exact setup last month, and the reference comment is spot on. For a lightweight URL check, spinning up a full ARC runner is overkill and will definitely feel wasteful in your billing. A simple ubuntu-latest runner is perfect here.

Here is the workflow snippet I use that covers most of your best practices:

on:
  schedule:
    - cron: '*/15 * * * *'

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Check URL
        run: |
          start_time=$(date +%s%3N)
          http_code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 --fail https://fdown.media)
          end_time=$(date +%s%3N)
          duration=$((end_time - start_time))
          
          echo "HTTP Code: $http_code"
          echo "Duration: ${duration}ms"
          
          # Write to summary
          echo "### 🟢 $http_code in ${duration}ms" >> $GITHUB_STEP_SUMMARY

A few tips from my experience:

1. Timeouts: Always use --max-time on curl so the job doesn't hang if the target is unresponsive.
2. Logs: Stick to the workflow summary ($GITHUB_STEP_SUMMARY) for quick visibility in the Actions UI. You rarely need to upload full logs as artifacts for a simple ping; it just clutters the repository.
3. Security: If your URL requires auth, make sure to use ${{ secrets.API_TOKEN }} and if there's any chance a token might leak in a verbose error message, wrap that step with ::add-mask:: immediately.

Since this is just a heartbeat check, I wouldn't touch ARC unless your other workflows force you to. Keep it simple, and you'll have a reliable monitor running for pennies.