Support

Most support requests are resolved on the first reply or the fifth, and the difference is almost always the information in the first message. This page tells you what to include, where to send it, how to check whether the problem is ours before you write, and how to report a security issue responsibly.

Before you write

Two checks take a minute and resolve a surprising share of reports.

Is the platform healthy? The status page reports current component health and any open incident. The same data is available programmatically:

bash

curl -s https://api.ospulse.app/api/v1/status/public

If an incident is open and it matches your symptoms, you do not need to write — subscribe to the incident instead (see Stay informed below) and you will be told when it clears.

Is it an error you can decode? Every API error is an RFC 7807 problem document with a detail field that says what went wrong, and validation failures list the offending fields under errors. A 401 almost always means an expired or revoked token; a 422 almost always means the body is wrong in a way the response spells out.

What to include

The correlationId is the single most useful thing you can send

Every error response carries a correlationId. It is the key that ties your exact request to the traces, logs, and metrics on our side. With it, we can usually find the failure in minutes. Without it, we are reconstructing what you did from a description — which is slow, and often inconclusive. If you log nothing else about an OSPulse error, log the correlationId.

json

{
  "type": "https://tools.ietf.org/html/rfc4918#section-11.2",
  "title": "One or more validation errors occurred.",
  "status": 422,
  "detail": "The request body failed validation.",
  "instance": "/api/v1/alert-rules",
  "correlationId": "9a2b7c14-3f80-4d61-b0c9-1e5f7d2a4c33",
  "errors": {
    "severity": ["'Critical' is not a valid PolicySeverity value."]
  }
}

Alongside the correlationId, include:

Endpoint and methodrequiredOptional

The full path as you called it, including query parameters — GET /api/v1/packages?ecosystem=Npm&take=100. Redact nothing except secrets; an ID that looks meaningless to you is how we find your tenant.

Timestamp in UTCrequiredOptional

When the request happened, to the second if you have it. Retention on detailed traces is finite, so a report about something that happened last month is much harder to investigate than one from this morning.

What you expected, and what happenedrequiredOptional

One sentence each. "I expected the scan to complete; it has been Queued for two hours" is a report we can act on. "Scans are broken" is not.

Status code and response bodyrecommendedOptional

Paste the whole problem document. The type and instance fields carry information the status code alone does not.

ReproductionrecommendedOptional

A curl command that fails, with the token replaced by $OSPULSE_TOKEN. If it only fails sometimes, say how often.

Client detailsoptionalOptional

CLI version, SDK or generated-client version, runtime, and whether it runs from a CI runner behind a proxy. Network-shaped problems look like API problems from the inside.

Never send us a token

Do not paste API tokens, credentials, or secrets into a support email, and redact any Authorization header before you copy a request. If a token has already been exposed, revoke it first and tell us second — see Authentication.

A template you can paste

text

Subject: [OSPulse] Scan stuck in Queued — correlationId 9a2b7c14-...
 
Correlation ID:   9a2b7c14-3f80-4d61-b0c9-1e5f7d2a4c33
When (UTC):       2026-07-28T09:14:22Z
Endpoint:         POST /api/v1/repositories/{repositoryId}/scan
Status returned:  202, then the scan stayed in "Queued"
Environment:      production (https://api.ospulse.app)
Client:           OSPulse CLI 1.4.2 on ubuntu-latest (GitHub Actions)
 
Expected:         the scan to progress to Running within a few minutes
Observed:         GET /api/v1/scans/{scanId} still reports Queued after 2h
Frequency:        3 of the last 5 scans on this repository
 
Reproduction:
  curl -X POST https://api.ospulse.app/api/v1/repositories/$REPO_ID/scan \
    -H "Authorization: Bearer $OSPULSE_TOKEN"
 
Response body:
  { ...paste the full JSON problem document, if there was one... }
 
Impact:           pull requests on <repo> are blocked on the gate

Fill in what you have; do not delay sending it because one line is missing. The subject line carrying the correlationId alone speeds things up measurably.

Where to send it

Email support

contact@fortitude-omnis.group — the fastest route for anything account-, billing-, or incident-related. Use the template above.

Contact form

Prefer a form, or asking a pre-sales question? The contact page reaches the same team.

OSPulse is operated by Fortitude Omnis Group Ltd, registered in England and Wales. Plan entitlements differ, including what support is included — see Pricing.

Stay informed

Rather than checking a page, subscribe once and let the platform tell you.

Status page/statusOptional

Current component health, open incidents, and their update history.

Public status APIGET /api/v1/status/publicOptional

The machine-readable summary — useful for an internal dashboard or a pre-flight check in a long-running job.

Atom feedGET /status/feed.atomOptional

https://api.ospulse.app/status/feed.atom — point a feed reader, a Slack RSS integration, or a Teams connector at it and incidents arrive where your team already is.

Email subscriptionPOST /status/subscribeOptional

Subscribe an address to incident notifications. You will receive a confirmation link (double opt-in), and every notification carries an unsubscribe link.

Status webhooksPOST /status/webhooksOptional

Register an endpoint to receive incident events directly, for teams that want to open an internal ticket automatically when a component degrades.

Planned changes and released fixes are published to the changelog. If a behaviour changed and you want to know when, read that before writing — and see Versioning & deprecation for what we promise about breaking changes.

Reporting a security issue

If you believe you have found a vulnerability in OSPulse, report it to us privately. We investigate every report and we will acknowledge yours.

Report privately — never in public

Email contact@fortitude-omnis.group with SECURITY in the subject line. Do not open a public issue, post the details on social media, or discuss them in a shared channel before we have had a chance to fix the problem. Public disclosure before a fix exposes other customers, not us.

Include enough to reproduce it

A report we can reproduce is a report we can fix. Please include:

The affected component — API endpoint, the web app, or the CLI — and the environment.
A clear description of the issue and the impact you believe it has.
Step-by-step reproduction, with requests or a proof-of-concept where relevant.
Any correlationId values from requests you made while testing.
How you would like to be credited, if you would like to be.

Test responsibly

Please stay within your own tenant and your own data. Do not run automated scanners or load-generating tools against production, do not attempt to access another tenant's data, and do not perform any test that degrades service for other customers. If a proof-of-concept requires going further than that, describe it and ask first.

What happens next

We acknowledge reports, assess the issue, and keep you updated on remediation. If a fix affects customers, it is published to the changelog. We would ask that you give us a reasonable opportunity to remediate before disclosing publicly.

Our security posture — how data is isolated, encrypted, and retained — is described on the security page.

Vulnerabilities in packages OSPulse tracks

A vulnerability in an open-source package that OSPulse reports on is not a vulnerability in OSPulse. Those should go to the upstream project's own disclosure process. If you think we are reporting it incorrectly — wrong severity, wrong affected range, a false positive — that is a normal support request, and the correlationId plus the package identifier is what we need.