# System and services

Distinguish repository structure, observed dependencies, and active checks.


## Two sources of health

**Runtime observations** come from the SDK's real calls. Supported databases, outbound APIs, and inbound webhooks can appear after traffic is observed. No extra availability request is needed for passive evidence.

**Manual monitors** make scheduled HTTP requests to a URL you configure. They provide an additional signal during quiet periods, but they consume requests on that destination.

## Read a health row

A service can be observed, waiting for traffic, healthy, warning, or down depending on the evidence and monitor state. Unknown days remain unknown. A 90-day strip is a display window, not proof that the platform monitored a service for 90 days before installation.

Service dependency detection is not authorization to a provider account. Seeing a Supabase hostname does not mean Everock has a Supabase management connection, and a repository mentioning Cloudflare does not prove deployed connectivity.

## Configure availability

Use a safe public health URL and enable or disable checks explicitly. The schedule supports 60–86,400 seconds. Failure, recovery, and latency-warning thresholds control incident promotion separately from scheduling.

The checker rejects private/internal destinations and validates redirects and DNS resolution. Supported monitor destinations are HTTP(S); this is not an unrestricted network probe or a database credential check.

## Other System views

Codebase shows submitted architecture data. Build/Git views depend on repository and release information. These complement health rather than replacing runtime telemetry.