AutoCore Monitoring and Health
Explains liveness, readiness, host monitoring, and external monitoring boundaries.
AutoCore exposes liveness and readiness information while external monitoring supplies alert routing and historical dashboards. Health is evidence about a check at a point in time, not a guarantee of business correctness.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Liveness | The health route returns service, version, uptime, edition, and credential-free provider summaries. |
| Readiness | Database, Redis, Meilisearch, storage, and payment checks use bounded timeouts; database failure returns unavailable. |
| Host monitor | The host script checks disk, memory, CPU, and container health and can push to an external uptime monitor. |
| Metrics | No native metrics exporter was verified in the source review; do not infer one from health routes. |
| Alerting | Define external ownership, thresholds, escalation, and maintenance windows outside the application. |
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.