github-activity-readme keeps a profile README current on a cron

The activity block is a README section filled in by a bot

The premise is narrow and easy to state: a profile repository has a README, and the README should show what the account has been doing. Doing that by hand means editing the file after every merge, which is exactly the chore people abandon after a week. This action removes the manual step by writing the section for you and committing the result on a timer. The README instructs you to place the comment <!--START_SECTION:activity--> inside README.md as the entry point, and points to the author's own profile repository as a working example. Everything else is automation around that marker. The project description says it updates README.md with the recent GitHub activity of a user, and the topics confirm the intended setting: profile-page, profile-readme, readme-template, github-action. It is a decoration tool, not an analytics one.

The workflow runs on a cron and commits with the Actions bot

Everything happens in a GitHub Actions workflow you write yourself. The action is consumed through a uses reference, with the token passed in as an environment variable, and the job is granted contents: write so the resulting commit can be pushed. The README example runs on ubuntu-latest with a half hour cron and also supports manual dispatch:

name: Update README
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:
jobs:
  build:
    name: Update this repo's README with recent activity
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - uses: actions/checkout@v4
      - uses: jamesgeorge007/github-activity-readme@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The checkout step is what gives the action a working copy of the repository to edit, and the token is what lets it push the commit back. The author notes that the job runs every half an hour and that you can change the schedule based on the cron syntax documentation.

Only four public event types reach the README

This is the constraint that decides whether the action fits your use case. The README states that only public events belonging to a specific list show up: IssueEvent, ReleaseEvent, IssueCommentEvent, and PullRequestEvent. Push events, commit activity, repository creation, and anything happening on private repositories never appear. A developer who writes a lot of code but opens few pull requests or issues will see an almost empty README, which is the most common reason a profile repository looks broken after installation. The same list appears in a different form in the FILTER_EVENTS input default, which is described as the option to display specific event types. The type names in that default are spelled IssuesEvent and PullRequestEvent rather than the singular forms used in the prose list, so anyone scripting against the filter should copy the exact string from the action's own documentation.

Input parameters change the committer, the file, and the line budget

The action exposes a table of input params that cover everything a user is likely to want to change. GH_USERNAME selects the account whose activity is summarised and defaults to your GitHub username. COMMIT_NAME and COMMIT_EMAIL set the identity on the commit; the name defaults to github-actions[bot]. COMMIT_MSG sets the message used when there is a commit to make, and EMPTY_COMMIT_MSG is used when there are no updates, which is how the workflow is kept active after a period of inactivity. MAX_LINES caps how many lines of activity are written, with a default of 5. TARGET_FILE selects the file to insert into and defaults to README.md. Here is the same job with the overrides applied:

name: Update README
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:
jobs:
  build:
    name: Update this repo's README with recent activity
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - uses: actions/checkout@v4
      - uses: jamesgeorge007/github-activity-readme@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          COMMIT_MSG: "Specify a custom commit message"
          MAX_LINES: 10
          COMMIT_NAME: GitHub Activity Readme

Overriding the committer name is worth doing if you would rather the commit history of your profile repository did not look like a machine wrote it.

An empty commit keeps the schedule alive during quiet months

The EMPTY_COMMIT_MSG parameter exists because of a specific GitHub behaviour rather than a stylistic preference. Scheduled workflows are disabled after a period of no activity in a repository, so a profile README that only commits when something interesting happened would eventually stop updating and never recover on its own. Committing even when the activity list is empty keeps the workflow active, and the default message for that case says as much in plain terms. It is a small, thoughtful detail, and it also has a cost: your default branch accumulates a commit every thirty minutes, forever, whether or not anything changed. For a repository you use as a public profile that is usually harmless. For a repository you also treat as a working codebase, the noise is a genuine cost to weigh before enabling the action.

The action ships as a bundled dist directory, not from source

The repository layout explains how this kind of action is normally consumed. The top level contains action.yml, index.js, package.json, a dist directory, and a package-lock.json. The package manifest names the entry point as index.js, depends on @actions/core and @actions/github, and declares three scripts: a prettier format check, a prettier format write, and a build step that runs ncc build index.js -o dist. That build step is the reason for the committed dist directory. GitHub Actions runners do not install your dependencies, they execute the action from the repository as it is checked out, so the bundled output has to be committed alongside the source for the action to work on a tag or a branch. The build uses @vercel/ncc as a dev dependency, and prettier handles formatting. The practical consequence for an adopter is that the action you reference with @master is running committed build output, so a change to the source is not visible until the dist directory is rebuilt and committed.

The alternative is activity-box, and the difference is the data source

The README credits JasonEtco/activity-box as the inspiration for this project. This action writes plain lines into your README and commits them, which means the result is plain markdown that renders identically on GitHub and on any mirror of your repository, and that the history of what you were working on is visible in the commit log rather than only at page load. If you want the activity recorded in your repository history, this is the one to use.

MIT licensed, with a release trail that tracks usage

The project is released under the MIT licence, so reuse, modification, and redistribution are permitted provided the licence notice is kept. The package manifest records the same MIT licence and names James George as the author. The last push to the repository was on 2026-08-05, and the recent tagged versions are v0.5.0 from 2026-03-15, v0.4.6 from 2026-01-01, and v0.4.5 from 2025-02-22. The default branch is master, and that is the ref the README's example workflow references, so a consumer is running whatever is currently on that branch rather than a pinned release. The repository also carries a CODE_OF_CONDUCT.md, a .gitignore, and a .github directory. The version numbering below one is a fair sign that the author treats this as a stable, small utility rather than a growing framework, and the missing homepage means the README is the whole documentation.

Editorial conclusion

Adopt github-activity-readme for a personal profile repository where the point is a visible, self refreshing activity list and you are comfortable committing to your default branch every thirty minutes. Do not adopt it if you need completeness, since only four public event types are captured, or if you want the activity of a user other than the repository owner without setting GH_USERNAME by hand. Before enabling it, add the <!--START_SECTION:activity--> marker to your README, confirm that your workflow file requests contents: write, and decide what MAX_LINES should be, because the default of 5 keeps the block short enough to hide most of what a busy account actually did.

Frequently asked questions

Official sources

1. Issues
2. jamesgeorge007/github-activity-readme on GitHub
3. License: MIT
4. README
5. Releases