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.
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
What does WebRun do on every run?
The exact actions WebRun takes, in order - in plain language, so you can adjust anything.
-
WebRun signs in and gets to work
Opens
postgresql.orgin a real browser with your saved login - no setup, no API keys. -
1
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.
-
2
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.
-
3
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.
How is each run configured?
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.
Every action is checked against this policy before it runs.
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.