By ChartNothing Product Team · Updated · 7 min read
How ChartNothing uses its own universal feed contract to present site health, connector failures, request volume, credit usage, and incidents without handing a connector full admin credentials.
Use the platform on itself
An operations dashboard is a useful proof because it has the same shape as many customer integrations: current metrics, time series, endpoint rows, incidents, and a compact status for mobile. ChartNothing admin metrics normalize users, connector runs, webhook activity, AI jobs, credits, billing state, and scoped-share reads into the same feed language used by external sources.
That feed can show whether the platform is healthy, degraded, or down without exposing raw account records. The public example uses synthetic or aggregate values; the live internal connector requires ADMINS group membership and server-side authorization.
Prefer a purpose-built read surface
A monitoring connector should not sign in as a human administrator and scrape a control page. The safer pattern is a narrow endpoint or internal function that returns the approved aggregate schema. ChartNothing can then pull it with a purpose-built token, or the monitored system can push a signed snapshot.
The response should exclude customer payloads, tokens, secret references, email addresses, payment details, and unrestricted log content. Human drill-down remains in the source system, while the feed carries enough state for triage and a link or identifier that an authorized operator can follow.
Make status explainable
A green badge without context is not an operational dashboard. The site metrics contract pairs a status with request count, error rate, freshness, active incidents, and check rows. If no traffic exists, it should say unknown or quiet rather than inventing uptime. If connector failures exist, the dashboard records their count and latest time instead of reporting the entire site as healthy.
For a watch surface, the reduction can be platform status as primary, error rate or open incidents as secondary, and freshness as the state. Notifications should be driven by explicit thresholds and deduplication, not every feed refresh.
Pull versus push for site metrics
Use scheduled GET when ChartNothing should own the observation cadence and the source can calculate a snapshot cheaply. Use a signed webhook for incident changes or systems that already aggregate health. It is reasonable to use both: a slower pull as a reliability baseline and event-driven pushes for material changes.
Whichever transport is selected, keep idempotency, quotas, freshness, and retry ownership clear. A one-minute producer does not automatically justify one-minute device delivery. The product can preserve the newest state and spend delivery budget when a surface or notification actually needs it.
Frequently asked questions
Does the ops connector need my full ChartNothing admin login?
No. The internal implementation uses group authorization and a purpose-built aggregate function. External sites should expose a narrow token or signed endpoint rather than a human session.
Can this replace a full observability platform?
It is a presentation and delivery layer for selected status data, not a replacement for raw logs, traces, metrics storage, or incident tooling.
Can incidents notify the phone and watch?
That is the intended delivery direction. Production notification rules still need device registration, APNs delivery, deduplication, retry, and user preference controls.