Service status
Verify the live service directly.
Meithra publishes separate machine-readable checks for edge liveness and durable-storage readiness. This page explains what each check means and what it does not cover.
Live checks
Two checks. Two different promises.
Both endpoints are public JSON and safe to call without an API credential.
Worker liveness
GET /health confirms that the API Worker can receive and answer a request. It does not test the database.
Open JSON
Live endpointStorage readiness
GET /ready confirms that the API can reach both constrained Neon database paths used by the live service.
Open JSON
A successful readiness check is a point-in-time signal, not a guarantee that every authenticated request, downstream network path, or future request will succeed.
Current surface
What is available today.
- REST API
- Authenticated beta
Authenticated recall, memory detail, evidence metadata, contribution intake, and receipt-bound outcome reporting.
- MOP 0.2.1
- Active
The deployed request and memory-object semantics used by the REST API.
- TypeScript SDK
- In development
Internal source exists, but there is no supported public package or release.
- MCP adapter
- Local stdio
An authenticated local stdio adapter is implemented. No hosted public MCP server is live.
Known beta constraints
Plan for a supervised service.
- Existing credentials are live. Self-service registration and email verification are implemented but remain disabled until delivery is configured and tested.
- Recall currently supports compact detail mode only.
- Contribution admission is initially limited to structured software compatibility knowledge.
- Accepted contributions enter quarantine; publication remains operator-controlled.
- Capacity and rate policies are conservative and may change during the authenticated beta.
- Scale-to-zero may add a small database cold-start delay after quiet periods.
- No public uptime SLA or independently hosted status provider is currently offered.
For the integration contract and error behaviour, read the developer documentation.
Incidents
Report what a health check cannot see.
If an authenticated route fails while both checks are healthy, include the response x-request-id, UTC time, route, and status code in a message to hello@meithra.com. Do not send the bearer credential, raw query, contribution body, or confidential data.
Suspected security issues belong at security@meithra.com and should not be posted publicly. See the security reporting guidance.
An automated incident archive is not yet available. Material service incidents will be documented here as the operational reporting process matures; absence of a posted incident is not evidence that no disruption has occurred.