All templates

Automated PostgreSQL EOL Tracking

Every Monday, WebRun opens postgresql.org, reads the versioning policy and the supported versions table, works out how many months each major version you run has before its end of life date, writes a countdown page in Notion, and keeps one upgrade row per database in Airtable.

Runs on WebRun · Strict Lockdown policy
Every Monday at 9:00 AM WebRunorchestrates each step
1 PostgreSQL read the support calendar
2 Notion publish the countdown
3 Airtable track each upgrade
In short

How do I track when my PostgreSQL version reaches end of life?

WebRun checks the PostgreSQL support calendar every Monday. It reads the versioning policy and supported versions pages on postgresql.org, calculates the months left before each major version you run reaches end of life, publishes the countdown in Notion, and tracks an upgrade window per database in Airtable.

  • Major upgrades get planned quarters ahead instead of forced
  • Every database has an owner and a target upgrade window
  • Versions inside their final year are flagged the week they get there

Built for engineering leads · platform teams · DBAs · DevOps teams

Step by step

What does WebRun do on every run?

The exact actions WebRun takes, in order - in plain language, so you can adjust anything.

  1. WebRun signs in and gets to work

    Opens postgresql.org in a real browser with your saved login - no setup, no API keys.

  2. 1
    PostgreSQL - read the support calendar
    postgresql.org
    WebRun in PostgreSQL: read the support calendar
    WebRun opens PostgreSQL to read the support calendar.
    • Open postgresql.org and go to the versioning policy and supported versions pages
    • Capture every major version with its end of life date
    • Match those against the major versions your team listed as in use
    • Read the release notes headings for anything that changes the upgrade path

    Done when Every major version you run has an end of life date and a months-remaining count.

  3. 2
    Notion - publish the countdown
    notion.so
    WebRun in Notion: publish the countdown
    WebRun opens Notion to publish the countdown.
    • Update the countdown page with one line per version: version, end of life date, months left
    • Put the version closest to end of life first
    • Add a short note when a version moved into its final year

    Done when The Notion page shows this week's countdown for every version in use.

  4. 3
    Airtable - track each upgrade
    airtable.com
    WebRun in Airtable: track each upgrade
    WebRun opens Airtable to track each upgrade.
    • Keep one Airtable row per database with its version, environment, and owner
    • Set the target upgrade quarter from the end of life date
    • Mark any database whose version has under twelve months left as needing a plan
    • Leave scheduling and approvals to the owner: WebRun only records the dates

    Done when Every database has a version, an end of life date, and an upgrade window.

Run settings

How is each run configured?

Starting pageWhere Chrome opens at the start of each run
postgresql.org
ScheduleRuns automatically on this cadence
Every Monday at 9:00 AM
DeliveryHow each run's result reaches you
Version countdown · Notion
OutputWhat each run produces - A weekly countdown of months remaining before each PostgreSQL major version you run stops getting fixes.
Text
Setup & safety

Secure by default

Connect once, stays signed in

WebRun signs in once and keeps each session in a persistent environment, so every run picks up right where it left off.

Your credentials stay in your own private environment - WebRun never stores your passwords.
Strict Lockdown

Every action is checked against this policy before it runs.

Domains ALLOWLIST
Typed input ALLOW
Shell command BLOCK
File uploads BLOCK
Runs in a contained environment More on policies
Good to know

Questions, answered

Does it touch my databases?

No. WebRun only reads the public support calendar on postgresql.org and writes to Notion and Airtable. It never connects to a database, runs a query, or starts an upgrade.

Where do the end of life dates come from?

Straight from the versioning policy and supported versions pages on postgresql.org, re-read every Monday, so the countdown reflects the project's own published calendar rather than a cached copy.

What if we run several major versions?

Each one gets its own line in the countdown and its own Airtable rows per database, sorted so the version closest to end of life sits at the top of the list.

Put this on autopilot.

Turn it on in minutes - or have our team set it up for you.