What does Factory monitoring measure?
Monitoring converts repeated observations into longitudinal evidence instead of a single status badge.
- Collection
- documentation
- Updated
- 2026-07-29
- min read
- 5
- Version
- v1
Monitoring records time-bounded reachability, protocol behavior, declared capabilities and selected compatibility checks with provenance and history.
Purpose
Monitoring converts repeated observations into longitudinal evidence instead of a single status badge.
Two tiers: best-effort and managed
Every plan gets at least best-effort observation. Managed (guaranteed) observation requires an active membership and an assigned monitoring slot.
| Tier | Guarantee | Notifications | Applies to |
|---|---|---|---|
| Best-effort | none | none | Free Listing, any lifecycle without an active managed slot |
| Managed | scheduled cadence | yes | Factory / Factory Pro / Factory Team, while membership is active |
Exact managed cadence and slot count by plan:
| Plan | Managed interval | Managed monitoring slots |
|---|---|---|
| Factory | weekly | 3 |
| Factory Pro | daily | 15 |
| Factory Team | every 6 hours | 50 |
Registration and claiming are unlimited on every plan, including Free Listing — but Free Listing can never hold a managed-monitoring slot, and a membership lapse suspends the managed slot (degrading to best-effort) without ever deleting lifecycle, claim, receipt or observation history. Cadence resumes automatically when membership becomes active again.
What each observation actually checks
Eight things, every run: reachability and endpoint identity; the initialize/tools/list inventory; authorized real-argument callability; schema, description, version and endpoint drift; latency, error and timeout behavior; distribution-target availability; crawler discovery reach; and usage/sales signals where legitimately available.
A baseline is recorded at shipment time and every scheduled run is compared against it. Failure classification is explicitly three-way — product_fault, provider_outage (DNS/hosting/network) or unknown — an outage caused by the creator's own hosting provider is never conflated with a defect in the product itself. An unmeasurable or unreachable condition is recorded as unknown; it is never guessed into a known passing or failing state.
What you actually receive
The current mechanism for checking status is calling Factory MCP tools directly (for example a status/station query), not a separate email inbox: email and webhook notification channels exist as designed but are explicitly not yet enabled — no email is sent until that channel is verified and switched on. Portal-inbox delivery is the one channel intended to be always-on for every plan.
On a failed managed run: bounded automatic retry with backoff, then a notification, then automatic recovery into reverification — the same guaranteed path either way.
Boundary and limitations
Monitoring is not continuous packet interception, universal security scanning or a guarantee of uptime.
Examples
2- 01
A tools/list schema change is recorded as a dated observation and linked to the prior version instead of overwriting history.
- 02
On Factory Pro (daily managed monitoring), a drift introduced Monday morning is typically caught and notified the same day; on Free Listing (best-effort only) the same drift carries no timing guarantee at all.