Service status

Uptime is the wrong question for a data service. This endpoint answers whether the answer you are about to get can be trusted: how far behind each source is, measured rather than promised, and which checks could not be made.

GET /api/v1/status

There is a human rendering of the same document at cve.vulnpatch.dev/signal. They read the same data, so they cannot drift.

Response

{
  "success": true,
  "data": {
    "answering": true,
    "safeToActOn": true,
    "measurementAvailable": true,
    "measurementStale": false,
    "primarySource": {
      "id": "cve-list-v5",
      "medianLagMinutes": 25.1,
      "p90LagMinutes": 61.1,
      "withinThirtyMinutesPct": 61.6
    },
    "sources": [
      {
        "id": "cve-list-v5",
        "count": 3030,
        "p50Minutes": 25.1,
        "p90Minutes": 61.1,
        "p99Minutes": 1321,
        "withinThirtyMinutesPct": 61.6,
        "ours": true
      }
    ],
    "kevEntries": 1705,
    "degraded": [],
    "unavailable": [],
    "measuredOver": 4524,
    "computedAt": "2026-09-11T11:31:45Z"
  }
}

The field that matters

safeToActOn goes false when a source an answer depends on could not be read. An agent about to change a production dependency can stop on this rather than discover the gap afterwards.

It is deliberately conservative. A missing freshness measurement sets it false even though the API is still answering, because a service that cannot say how fresh its data is has no business telling you it is fresh.

What the latency means

Latency runs from a record being published to this service being able to serve it. It therefore includes the publisher's own propagation as well as ours, and upstreamAvailableAt on a record is what separates the two where the source provides it.

Sources are reported separately, never blended. Their tails differ in kind: the CVE Program list is a live feed, GitHub republishes historical advisories in bulk, and the NixOS security review waits on human adjudication. A single combined number would describe none of them.

Only the source marked ours: true has a latency this service controls.

ENISA EUVD appears among upstream dependencies. A scheduled archive walks publication months and separately revisits records by update date. Its euvdCoverage block reports historicalRecords from completed publication windows, the dated sourceTotal observed at ENISA, historicalPercent, lastCompletedMonth, scanningMonth, scanningUpdatedDay, scanningUpdatedPage, updatedThrough and lastSuccessfulAt. updatedThrough is null until the first update-date window has completed; it is not an error while scanningUpdatedDay and scanningUpdatedPage show active progress. A partial backfill is not reported as a complete mirror. The percentage is backfill progress, not proof that every record is current. The EUVD row is marked mirrored only after the historical count agrees with the observed total and the update scan and source count are recent. An absent block means no successful archive checkpoint has been reported; an outage does not turn a partial archive into a complete one. Exact-ID lookups prefer ENISA and can use verified archived records if ENISA is unavailable.

What it does not measure

Records never indexed do not appear here, so this measures latency and not coverage. A source that is silent about a CVE contributes nothing to these figures.

Honest absences

• measurementAvailable: false means no measurement exists. It is never reported as zero latency.
• measurementStale: true means the measurement is over two hours old and describes a service that has since moved on.
• kevEntries: 0 means the exploitation catalogue could not be read, which is not the same as nothing being known-exploited.