GitHub Actions Timeout

Introduction

GitHub Actions is a CI/CD tool that allows you to automate your workflow. Because GitHub Pro plan allows users to run workflows for 3000 minutes per month for free for both public and private repositories, I have been using GitHub Actions to do a few lightweight routine tasks, such as web crawling and generating web pages. 3000 minutes per month is more than enough for my use cases. However, last month, I started to receive emails from GitHub notifying me that I was reaching and finally reached the limit of GitHub Actions free service. My daily spending was around 600 minutes per day. I was extremely surprised because all my scheduled workflows used to take no more than 15 minutes to complete in total.

It turns out that it was because the web crawling program in one of my scheduled daily workflow started to fall into an infinite for loop after the website I targeted changed its URL pattern. Therefore, the program was running indefinitely, and the workflow was only killed because it reached the default maximum timeout of 6 hours.

In this blog post, I will demonstrate how to check the problematic workflow that is consuming too much time and how to set a timeout for each job in your workflow.

GitHub Actions Timeout

GitHub Actions Usage Detailed Report

When I got the timeout email from GitHub, I was very confused and did not know what to do. The GitHub Billing & Plans page seemed to only show the total minutes used in the current month, but not the minutes used by each workflow.

To check the minutes used by each workflow, it turns out that there is a “Get usage report” button that we can click at the upper right corner of the monthly usage report. After clicking the button, GitHub will send the user an email with a detailed usage report, including the minutes used by each workflow, in a CSV file. I was able to locate the problematic workflow that was consuming too much time by this method.

Setting Timeout for Each Job in a Workflow

The default 6 hours timeout for each job in a workflow is too long for most of the individual users. It turns out that we could set a timeout for each job in a workflow by using the timeout-minutes attribute. Here is an example from the workflow of my GitHub Self-Updating Repository Demo.

name: GitHub Self-Updating Repository Demo

on:
  # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
  schedule:
    # The shortest interval you can run scheduled workflows is once every 5 minutes.
    # Note: The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs.
    # High load times include the start of every hour.
    # To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
    # Every 5 minutes.
    # - cron: '*/5 * * * *'
    # At the beginning of every day.
    - cron: "0 0 * * *"

# on: [push]

jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository code
        # https://github.com/actions/checkout/tree/v3.0.2
        uses: actions/checkout@v3
      - name: Modify date and time
        run: |
          date > README.md
          cat README.md
        timeout-minutes: 2
      - name: Push to repository
        run: |
          git config --global user.name "Lei Mao"
          git config --global user.email "leimao@users.noreply.github.com"
          now=$(date)
          git add -A
          git commit -m "Auto Push on $now"
          git push

Conclusions

For individual users, to avoid unexpected usage and cost of GitHub Actions, or any other CI/CD tools, it’s always a best practice to set a timeout for each job in your workflow, especially for those running fragile and unstable programs.