Telemetry feed
Status
This page documents status reporting; it is not a live health feed.
Mayospell has not connected these rows to production monitoring. Do not rely on this route to decide whether the trading workstation, market data, webhooks, billing, payouts, or support are currently operational.
Core systems
6 tracked
Current rows
Reference model
Desk expectation
Stop, verify, escalate
Status snapshot
Mayospell status language is documented here, not reported live.
The cards below describe the evidence and language Mayospell will need before this route can make current uptime claims.
Mayospell status snapshot: July 5, 2026. Current Mayospell status posture: a reference model for room, data, API, billing, payout, and support incidents while production telemetry remains unconnected.
Status belongs in public
Mayospell documents status as a first-class support surface, but this page is not connected to production telemetry.
Maintenance should be visible
Planned maintenance reporting will cover platform, market-data, and dashboard work once a monitored production status feed exists.
Incidents need plain language
The example states below show how desk, data, webhook, and payout incidents will be explained; they do not report current incidents.
Status supports trust
A production status page will need monitored sources and timestamps before Mayospell can make current uptime claims.
System health
Every tracked lane is currently marked as unmonitored here.
System names are real product areas; their displayed states are disclosure boundaries, not automated health checks.
System
Mayospell scope
Mayospell
Current state
Trader portal
Mayospell plans to report homepage, dashboard, seat, billing, and review updates from one public status surface.
Planned monitoring scope: homepage, dashboard, seat pages, billing, and review surfaces.
Not monitored here
Trading workstation
Mayospell's options room is the operating center for account state, orders, and risk controls.
Planned monitoring scope: options room, order ticket, manual lockout, bracket presets, and desk-TV overlays.
Not monitored here
Market data
Real-time data access and add-on depth are explicit parts of the public product.
Planned monitoring scope: chain, greeks, quote, and any future depth or flow services.
Not monitored here
Webhook and API rail
Mayospell exposes a separate API lane and keeps hosted incidents distinct from member-local automation.
Planned monitoring scope: hosted API and webhook services. Member-local automation remains outside Mayospell uptime reporting.
Not monitored here
Payout and billing queue
Mayospell intends to treat payouts, resets, and rebills as explicit operating surfaces when those services are connected.
Planned only. Mayospell has no operating payout, reset-purchase, Reset Bank, or KYC-gated purchase rail to monitor today.
Not monitored here
Support concierge
Mayospell currently provides self-service articles and stored Contact intake, not a staffed concierge system.
Not available. Mayospell currently provides self-service articles and stored contact intake, not a staffed concierge system with uptime promises.
Not monitored here
Incident examples
Market-data degradation
ReferenceExample
Illustrative incident copy: identify which data lane is delayed, whether core quotes remain usable, and when the last monitored update occurred.
Webhook retries elevated
ReferenceExample
Illustrative incident copy: separate a hosted relay problem from member-local automation and tell users what evidence to preserve.
Member portal available
ReferenceExample
Illustrative incident copy: report unaffected services separately instead of implying that every Mayospell system shares one health state.
No live telemetry on this page
Not connectedCurrent disclosure
These rows are product examples, not a live incident log. Do not use them to decide whether an order path, market-data feed, or member service is currently healthy.
Status states
Operational
All public and member systems are serving normally. The page still shows the latest scheduled maintenance and the most recent resolved issue.
Monitoring
A nonfatal degradation exists in one lane such as advanced data, API relays, or payout processing, but the core room stays usable.
Investigating
The desk has enough evidence to acknowledge a problem publicly and is actively tracing it before asking traders to guess.
Resolved
The incident is closed, the timeline stays visible, and the desk makes clear what traders should verify before resuming normal behavior.
Desk rules
A status page only matters if it changes trader behavior in the right direction.
The point is not drama. The point is fast, clear, disciplined response.
When room behavior looks wrong, traders should stop fresh entries before they start troubleshooting.
A public status page should distinguish between full platform outages, degraded add-ons, and member-local automation problems.
Scheduled maintenance belongs on the same page as live incidents so traders learn one place to check first.
Status should link directly back to Help, Support, and the room evidence workflow instead of behaving like a dead-end notice board.
Linked routes
Use linked routes for context, not as proof of current health.
Support, Help, and the workstation remain reachable, but this page cannot clear a trader to resume activity.
Support center
Escalate platform, payout, or automation issues through the same desk workflow that references status and evidence together.
Help center
Use article-level policy answers before opening a human case when the issue is rules, billing, or payout interpretation.
Trading room
Open the workstation separately; this status page cannot confirm whether its data or order services are healthy.
Member POP center
Open the member proof archive when a payout, release timing, or lane label needs account-level verification.
Visible proof
No verified payout records are attached to status.
Sample POP records are not operational evidence and are excluded from this page.
No settlement-backed Mayospell payout artifacts are published.
Next surface