Skip to main content
GET
Monitoring Status

Overview

A single, read-only snapshot of your whole monitoring program. It answers two different questions in one response:
  • How are my watches doing? The watches block is a rollup of every watch in your organization, counted by health state. It is scoped strictly to your org.
  • How fresh is Signa’s data for each office? The offices[] block is Signa’s global per-office ingestion freshness. It is the same for every organization, computed once and shared through a 60 second cache, and it is not filtered to the offices your watches cover.
A third block, pipeline, carries the continuous end-to-end verification gauges. Every timestamp in it is null-honest: a missing or stale check is reported as null, never as an old value dressed up as a fresh verification. Requires the portfolios:manage scope. Calling it never changes anything.
slo_hours is an internal freshness target, not an SLA. Each office carries an slo_hours value derived from that office’s update_cadence. It is the ceiling Signa uses to decide pipeline_status: coverage within slo_hours is ok, coverage older than that (or no coverage signal at all) is lagging. It is an operational default that Signa can tune as an office’s publishing behaviour changes. It is not a published service level and not a contractual commitment.

Query Parameters

None. The response is always the full snapshot.

How to use it

Gate a “no conflicts” report. Before you tell a client that a watch surfaced nothing, check that every office the watch covers reports pipeline_status: "ok". A lagging office means the register data behind that negative result is older than Signa’s own freshness target, so the report should say so or wait. Drive a dashboard tile. The response is one call, small, and safe to poll. Show watches.by_health as a status strip and offices[] as a freshness table. Because offices[] is global, you can cache it across users and orgs. Run your own alerting. Poll on a schedule and alert when watches.by_health.degraded > 0, when an office you rely on flips to lagging, or when pipeline.last_verified_end_to_end_at turns null. This is the same signal the dashboard Monitoring page reads. For the meaning of each health state and the reasoning behind the null-honest gauges, read the Monitoring status guide.

Response

string
Always monitoring_status.
object
Org-scoped aggregate over all of your non-deleted watches.
object[]
Global per-office pipeline status, one entry per live office. Not org-specific: identical for every organization, computed once and shared through a 60 second cache.
object
Continuous pipeline-verification gauges. Both timestamps follow one rule: a stale value is never presented as a fresh verification.
string
Request identifier for support.

Errors

Code Examples