Support

Before contacting support

Check the status page first:

https://status.frem.sh

Active incidents and maintenance windows are posted there. If the issue you are seeing matches an active incident, no action is needed from your side.

Subscribing to status updates

Three ways to be notified of incidents and maintenance windows without polling the page:

RSS / Atom feed: https://status.frem.sh/feed.atom, point any feed reader (NetNewsWire, Feedly, Slack RSS app, etc.) at this URL.
JSON incident API: https://status.frem.sh/api/v1/incidents, for custom integrations.
Webhook subscription for your org: at Org admin → Webhooks → Destinations → Add a destination (/<org>/_admin/webhooks/destinations), point a webhook at your incident-handling endpoint and select status_incident in the events picker. Each Severity-1 incident affecting your org also triggers an email to the admin-of-record automatically per SLA §9, no setup needed for that channel.
Each delivery POSTs the following JSON body to your endpoint, signed with HMAC-SHA256 in the X-Fremforge-Signature header:
```
{
  "event": "status_incident",
  "incident_id": "aaaaaaaa-aaaa-4aaa-8aaa-000000000001",
  "monitor_id": 42,
  "monitor_name": "API (frem.sh/_app/healthz)",
  "status": "down",
  "heartbeat_status": 0,
  "message": "Timeout after 5s",
  "started_at": "2026-05-15T14:32:01.000Z"
}
```
status is one of down (heartbeat_status=0), up (1), pending (2), maintenance (3), or unknown. incident_id is stable across retries, fremforge re-delivers the same incident_id on transient failures; use it for idempotent handling on your side.

The admin-of-record email contact is set at Org admin → Billing → Billing contact. Keep it current; fremverk’s incident notification commitment depends on reaching a working address.

Contact channels

Purpose	Contact
General support	support@frem.sh
Security vulnerabilities	security@frem.sh, do not report publicly

Do not report security vulnerabilities via the general support address or publicly. See the Security page for responsible disclosure procedures.

Severity levels and response targets

Response times are first-response targets measured from the time the email is received during business hours.

Severity	Definition	First response
P1, Critical	Production org unavailable, all users unable to authenticate, data loss risk	2 business hours
P2, High	Core feature unavailable (CI runners down, SSO failing for most users)	4 business hours
P3, Medium	Degraded performance, single-user issue, non-blocking	1 business day
P4, Low	Questions, feature requests, general usage	2 business days

Classify your request by impact. If you are unsure, describe the scope of impact in the email and support will assign severity.

Business hours

Support is available 09:00-17:00 CET/CEST, Monday through Friday, excluding Danish public holidays.

P1 and P2 issues submitted outside business hours are triaged at the start of the next business day.

What to include in your email

Include the following to avoid back-and-forth:

Org slug: the <org> part of your fremforge URL
Affected users: username(s) or “all users in the org”
Steps to reproduce: what you did, what you expected to happen, what actually happened
Error messages: paste the full error text or attach a screenshot
Workflow run IDs: for CI issues, include the run URL (frem.sh/<org>/<repo>/actions/runs/<id>) or the run ID from the logs
Timestamps: when the issue started, whether it is ongoing or intermittent

The more context you provide in the first email, the faster support can respond.

Full SLA

The full SLA with uptime commitments, measurement methodology, and remedy credits is at:

https://www.frem.sh/legal/sla/

Cross-references

Troubleshooting, self-service fixes for common issues
SSO break-glass, recovering org access when the IdP is unavailable
Two-factor authentication, 2FA recovery when the authenticator is unavailable
Security and supply chain, responsible disclosure for security vulnerabilities