Yes — two different lifetimes are involved, and you’re caching the wrong one for too long:

The app JWT (signed with your private key, RS256) is valid for at most 10 minutes. It’s only used to talk about the app itself and to mint installation tokens.
The installation access token is valid for 1 hour. That’s the one you use for repo API calls, and it’s what’s expiring in your service.

So the fix is to treat installation tokens as short-lived credentials: cache them per installation with their expires_at, and mint a new one when they’re within a minute or two of expiry. Don’t store them at process start.

Minimal version with Octokit, which does the caching/refresh for you:

import { App } from "octokit";

const app = new App({
appId: process.env.APP_ID,
privateKey: process.env.PRIVATE_KEY, // PEM contents, newlines intact
});

// Per request: get an Octokit bound to that installation.
// The token is minted lazily and refreshed automatically before it expires.
const octokit = await app.getInstallationOctokit(installationId);
await octokit.rest.issues.createComment({ owner, repo, issue_number, body });

If you’re hand-rolling it, generate the JWT with iat set ~60 s in the past (clock drift) and exp ≤ iat + 600, then call POST /app/installations/{installation_id}/access_tokens and keep the token until expires_at minus a safety margin.

The 403 Resource not accessible by integration on one repo is a permissions problem, not an auth one. Common causes:

You added a permission (e.g. Pull requests: write or Issues: write) to the app after it was installed there. Permission changes aren’t applied until the org/user owner accepts them — check the installation page under Settings → GitHub Apps.
The app is installed on the account with “Only select repositories” and that repo isn’t in the list.
You’re requesting a token scoped with repository_ids or a narrowed permissions object that doesn’t include that repo or permission.