Scheduled Workflow Observability in Github Actions

Since its launch in 2018 Github Actions has become a major player in the CI space thanks to its familiar workflow syntax, tight integration with Github repositories and the breadth of the re-usable actions available.

Although long term I do have some reservations about how much of the developer ecosystem Microsoft now owns I'm overall very happy with Github Actions and tend to default to it on new projects.

There is a small issue with the observability of scheduled workflows that I wanted to highlight though. Luckily the solution is very straightforward.

The Problem

The issue is that only the person who created a scheduled workflow gets notified when it fails and those notifications go via email. This is a problem for a few reasons:

  • It doesn't integrate well with support rotas or tooling
  • It will silently fail when the workflow creator leaves your organisation
  • Email isn't typically the best way to get a dev's attention quickly


Thankfully Github offers the ability to run additional workflow steps on failure, so we can use that to send a notification via if: failure().

To send a notification via Slack we can make use of the Slack send action. Putting that all together we get:

- name: Send failure message
  if: failure()
  uses: slackapi/slack-github-action@v1.24.0
   payload: |
    "repository_name": "${{ github.repository }}",
    "workflow_name": "${{ github.workflow }}",
    "build_url": "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"

Slack send has a few different ways of setting things up so check the docs for full details. The way I've shown here is the recommended approach with Slack webhooks. You can define custom variables in your webhook, in this case I created repository_name, workflow_name and build_url then the payload to the webhook needs to include values for all of the variables you have defined.

The webhook then allows you to define a message which is sent to a particular channel using the variables as template values.

Populating the build URL in the Github action was a bit messy as (at the time of writing) it isn't exposed as a single value anywhere, but overall the solution is fairly robust.


This was fairly simple to set up and seems pretty effective so far, hopefully you found it helpful!