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.

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.

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.

@edwardjames12

Best solution

Use GitHub-hosted runners (ubuntu-latest) + scheduled workflow.
Skip ARC.

• Quick HTTP check → no need for self-hosted runners
• Cron (5–15 min) — not precise, can delay 10–60+ min
• curl --max-time + job timeout
• Result → $GITHUB_STEP_SUMMARY
• Artifact only on failure
• Alert on failure (issue/webhook)

Better option: Upptime (status page + history, still zero infra)

Use ARC only for private network or custom tools.

For something this lightweight I wouldn't reach for ARC at all — hosted runners on a scheduled workflow are a much better fit. A monitoring check that sends an HTTP request and logs the result doesn't justify the overhead of managing runner infrastructure, and with schedule triggered workflows on hosted runners you're only paying compute for the seconds the job actually runs.

For the periodic check itself, curl with --max-time and --write-out handles timeouts and response time measurement cleanly without pulling in any dependencies:

yaml

• name: Check endpoint
  run: |
  RESULT=$(curl -o /dev/null -s -w "%{http_code} %{time_total}" --max-time 10 https://example.com)
  echo "Response: $RESULT" >> $GITHUB_STEP_SUMMARY

Writing to $GITHUB_STEP_SUMMARY gives you a readable result per run without storing artifacts you don't need — reserve artifacts for cases where you're capturing response bodies or need something to persist across runs for trend analysis.

For credentials, Actions secrets passed as environment variables never appear in logs as long as you're not explicitly echoing them. The runner masks them automatically.

If you do eventually need ARC for scale, ephemeral runners per job is the right model for monitoring — a runner that sits idle between scheduled intervals is wasted resource and introduces state drift risk. But for what you're describing, hosted runners with a cron schedule is simpler and more reliable.

For a lightweight monitoring task with ARC, it is best to use ephemeral (short-lived) runners that spin up on demand, rather than keeping a runner constantly running. Since the checks are quick, ephemeral runners prevent resource waste and ensure a clean environment for every run.
For best practices:
• Timeouts: Use the timeout-minutes property in your GitHub Actions step/job to prevent the runner from hanging if the site is down.
• Secure logs: Use GitHub Secrets to automatically mask any sensitive data in the logs.
• Lightweight results: Save logs as Workflow Summaries (quick Markdowns) instead of creating heavy build artifacts every few minutes.

Use a plain GitHub-hosted runner (ubuntu-latest) without ARC at all**, because the task is very lightweight and running ARC or a persistent runner would be a waste of resources and billing【turn1fetch0】【turn3fetch0】.

The recommended workflow:

name: URL Check
on:
  schedule:
    - cron: "*/15 * * * *"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 3
    steps:
      - name: Check URL
        env:
          URL: https://example.com
        run: |
          code=$(curl -sS -L -o /dev/null --connect-timeout 10 --max-time 20 \
            -w '%{http_code}' "$URL") || exit 1
          echo "| $URL | $code |" >> "$GITHUB_STEP_SUMMARY"
      - name: Save result
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: url-check-result
          retention-days: 7

• Runner: ubuntu-latest — and if you're already using ARC, make the runner ephemeral (created and destroyed per check), not a persistent one.
• Timeouts: Three layers — --connect-timeout 10 and --max-time 20 in curl + timeout-minutes at the job level.
• Results: Write a summary to $GITHUB_STEP_SUMMARY instead of uploading full logs, and keep the artifact as a small JSON file with retention-days: 7.
• Security: Never put tokens in the URL (they appear in logs), use ${{ secrets.XXX }} via env, and use ::add-mask:: for values generated at runtime.
• Important caveat: Scheduled cron workflows in Actions are not precise and can be delayed, so for serious uptime monitoring a dedicated monitoring service is better; for lightweight use, this solution is sufficient and excellent.

Bottom line: GitHub-hosted runner + cron + curl with timeouts = the optimal solution for your task, and ARC is unnecessary here.