Offer: self-updating EOL badge for your supported-versions table

[endoflife-ai]

Hi — I noticed you maintain the Node.js versions Bolt supports by hand in your README. We run endoflife.ai (lifecycle data for 488 products, built on the endoflife.date community dataset — we're contributors) and publish free Shields.io endpoint badges that show live support status:

[![Node.js EOL](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fnodejs.json)](https://endoflife.ai/nodejs)

When a version reaches end of life, the badge updates itself — no README edits, no CI. There are per-version badges too (e.g. pin the minimum version you support, so the badge flips the day your floor goes EOL). No signup, no tracking, no API keys — they're static JSON endpoints in the Shields endpoint format, regenerated nightly from vendor lifecycle policies.

If it's useful, the copy-paste snippet for your stack is one click at endoflife.ai/badge; if not, feel free to close this — no hard feelings. Not affiliated with any of your dependencies; just trying to make EOL status visible where people actually look. (Background: why we built these.)

[zimeg]

Hey @endoflife-ai! 👋 Thanks for taking notice and sharing this badge with us 🏆

I'm hesitant to add this to our documentation right now for a few reasons:

• Node 26 is in "current" development and while we hope to test this with ci: add Node 26 to the test matrix #2990 it's not recommended for application use at this time.

  Production applications should only use Active LTS or Maintenance LTS releases.
  🔗 https://nodejs.org/en/about/previous-releases

• We focus more often on the minimum supported Node version of a package with assumption that ongoing releases remain compatible within a major version.

• At this time our CI serves as a source of truth for compatible versions. I do agree we can surface similar better in README but we might consider revisiting our own pages around Node support too:
  🔗 https://docs.slack.dev/tools/node-slack-sdk/support-schedule

Let's keep this idea open for thoughts because I might be missing some capabilities of these badges! FWIW I think badges of the current @slack/bolt version would also be neat to have 🔭

[endoflife-ai]

Hey @zimeg, thanks for the thoughtful look! 👋 Both your concerns are right about the badge I showed — and they're exactly what the per-version badges are for, which I should have led with.

The top-level /badge/nodejs.json tracks the newest release line, LTS or not — so for Node specifically it can surface a "current" line like 26, which as you say isn't what production users should key off. Fair hit.

The per-version endpoints avoid that entirely: one badge per release line, each showing that line's own lifecycle status. A row of them for the lines in your support schedule looks like this today:

[![Node 22](https://img.shields.io/endpoint?url=https%3A%2F%2Fendoflife.ai%2Fbadge%2Fnodejs%2F22.json)](https://endoflife.ai/nodejs/22)

Two things worth noting about the fit for your case:

• These make no claim about bolt-js itself — each badge states the runtime line's own upstream lifecycle ("v22.23.1 · EOL Apr 2027"), which is the input your support schedule already keys off. When a line flips red, that's precisely the moment your schedule page gets its next row — the badge just makes the countdown visible in the meantime.
• If the support-schedule page would rather consume raw dates than badges, the same data is available as plain JSON (no key, no rate limits beyond Shields' caching): https://endoflife.ai/badge/nodejs/22.json, or the fuller lifecycle API documented at endoflife.ai/api.

On the @slack/bolt version badge — agreed that'd be neat, and it already exists upstream: Shields' own npm badge (https://img.shields.io/npm/v/@slack/bolt) does exactly that, and would sit nicely next to a runtime-lifecycle row.

No pressure on where (or whether) any of this lands — README, docs page, or nowhere is all good. Happy to answer anything else about how the endpoints behave.