Admin notifications
fremforge surfaces operational issues across three channels:
- Bell — the bell icon in the top bar of
/<org>/_admin/*. Per-admin, last 30 days, click-through to the relevant settings page. - Settings-page banner — a sticky banner at the top of the relevant settings page (e.g. SSO settings page banners the SSO cert expiry). Cleared when the underlying condition clears.
- Email — sent to org admins for critical conditions. We deliver via Lettermint (EU sub-processor); the template source lives in-repo so the body is auditable.
The same condition can fire on multiple channels. Email is always paired with bell + banner; banners are always paired with bell; bell-only items are non-critical.
Conditions today
| Condition | Bell | Banner location | Notes | |
|---|---|---|---|---|
| PAT expiring (org-scoped) | yes | /_admin/integrations/pats | yes | Ladder: 30 → 14 → 7 → 1 day |
| Webhook destination failing | yes | /_admin/integrations/webhooks | yes | Threshold: 5 consecutive failures in 24h |
| SSO cert expiring | yes | /_admin/auth/sso | yes | Ladder: 30 → 14 → 7 → 0 day |
| Stale invitations | yes | /_admin/members/invitations | no | Invitations unactioned >30 days |
| Legal docs drifted | yes | /_admin/legal/changelog | no | Acknowledge to clear |
| Legal hold active | yes | /_admin/compliance/legal-hold | yes | Bell stays sticky until hold lifted |
| Audit chain integrity | yes | /_admin/compliance/audit-chain | no | Surfaces broken, partial, anchor_mismatch |
| Runner-burn projection | yes | /_admin/billing | no | Skipped during Day 1 of a new billing period |
| Storage quota approaching | yes | /_admin/billing | yes | Fire at >=90%, clear at <80% |
| Critical SAST findings open >7d | yes | /_admin/security/findings | no | Severity critical only |
| Sub-processor change pending | yes | /_admin/compliance/sub-processors | yes | DPA §14 notification |
User-scoped notifications (also delivered via Lettermint):
| Condition | Recipient | |
|---|---|---|
| User PAT expiring | PAT owner | yes |
| Export failed | requester | yes |
How to clear each alert
PAT expiring
Rotate the PAT at /<org>/_admin/integrations/pats and re-issue. The new PAT starts a fresh expiry clock; the bell clears the next morning.
If the owner has left the org, the PAT can be revoked outright from the same page. There is no “extend” — by design.
Webhook destination failing
Two paths:
- Destination is genuinely broken. Edit it at
/<org>/_admin/integrations/webhooksand either fix the URL/secret or delete the destination. The bell clears within 24h once health returns to baseline. - Destination is temporarily down. Mark it
paused=trueto silence the alert without deleting history. Unpause when the receiving service is healthy again.
SSO cert expiring
Rotate the IdP signing cert in your IdP, then either:
- Wait — the daily probe at
/jobs/sso-cert-expiry-checkpicks up the new cert and clears the warning ladder. - Hit “Test SSO” on
/<org>/_admin/auth/ssoto re-probe immediately.
The cert probe goes through fremforge’s outbound proxy (no direct egress from the API pod), so allow-list rules apply — verify your IdP is reachable from the outbound proxy if probing fails.
Stale invitations
Either re-send (refreshes the expiry) or revoke. Stale invitations don’t expose tenant data — the bell exists to keep the member list tidy.
Legal docs drifted
When fremverk publishes a new version of Terms, DPA, or AUP, the bell fires for every org. Visit /<org>/_admin/legal/changelog to see the diff and acknowledge — the bell clears for your org.
Acknowledging records who and when, for the customer record.
Legal hold active
This bell does NOT clear automatically. Lifting a legal hold requires:
- Documenting why (audit trail goes to the LTS archive bucket).
- An operator action at
/<org>/_admin/compliance/legal-hold.
The bell is intentionally sticky so it remains visible to every admin throughout the hold period — DPA §9 retention deviations need to be impossible to forget.
Audit chain integrity
Three possible non-ok states:
broken— chain walk failed at some row. Page on-call.partial— chain walk truncated by row-cap (very large tenants). Re-run with a higher cap window scheduled.anchor_mismatch— the on-disk hash chain doesn’t match the OBS WORM anchor. Page on-call immediately.
In every non-ok state, contact support@frem.sh with the tenant slug — we’ll dispatch.
Runner-burn projection
Surfaces if your monthly runner-minute burn projects to exceed the included quota. Actions:
- Adjust runner concurrency caps at
/<org>/_admin/runners/concurrency. - Increase your plan (one-off bumps available at
/<org>/_admin/billing). - Acknowledge to dismiss for the rest of the current period.
Storage quota
Hysteresis: alert fires at ≥90% of plan storage, clears at <80%. Actions:
- Delete unused repos or LFS objects.
- Move large artifacts off to your own OBS bucket and reference by URL.
- Upgrade your plan.
Sub-processor change pending
When fremverk adds a new sub-processor that processes tenant PII, DPA §14 requires us to notify you with a 30-day acknowledgement window. The bell lists the change and links to the proposed DPA Annex B diff at /<org>/_admin/compliance/sub-processors.
Acknowledging accepts the change; objecting triggers the contractual escalation path described in your DPA.
Email delivery
All emails come from notifications@frem.sh. Reply-to is support@frem.sh (replies route to the support queue, not to a black-hole address).
If you’re missing notification emails:
- Confirm the org-admin email is current at
/<org>/_admin/members. - Check that
notifications@frem.sh(andfrem.shSPF) isn’t quarantined upstream. - Verify the alert is actually firing — the bell is authoritative; email is a courtesy.
We do not retry bounced notification emails. The bell remains lit until the underlying condition clears — the bell is the source of truth.
What’s NOT surfaced
Things deliberately not in the admin notification surface (by design):
- Per-PR / per-commit notifications — those live in your repo’s notification settings, not the admin console.
- Forgejo system alerts (mirror sync failures, push rule violations) — those go to the affected repo’s settings page, not the admin bell.
- Billing failures — handled through the billing email + dunning flow, not the bell.
If something feels missing, file an issue at frem.sh/_app/feedback. We add alerts where the cost of missing the event > the cost of the noise — the bar is genuinely high.