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.