Skip to content
System Status

MailFrame status

Current operational status of MailFrame services. This page is served at status.mailframe.ai.

All systems operational

Status shown reflects MailFrame's posted operational posture, maintained by the team. Automated uptime telemetry and real-time incident feeds are connected at deploy/configuration time for the production status.mailframe.ai deployment. For a programmatic liveness signal today, poll GET /health.

Components

  • API
    REST API at api.mailframe.ai — authentication, schemas, parses, usage.
    Operational
  • Parse engine
    Email-to-JSON extraction and schema validation behind POST /v1/parse.
    Operational
  • Dashboard
    app.mailframe.ai — sign-in, API key management, onboarding.
    Operational
  • Docs
    Documentation and API reference at docs.mailframe.ai.
    Operational
  • Webhook delivery
    Signed async delivery, retries, and dead-letter replay. Early access.
    Operational
  • Inbox ingest
    Inbound email forwarding to unique parse addresses. Early access.
    Operational

Incident history

No incidents reported.

Resolved incidents will be listed here with their full timeline.

Uptime & incident policy

What we monitor
Availability and latency of the public API, the parse engine, the dashboard, docs, and (in early access) webhook delivery and inbox ingest. Each maps to a component card above.
Severity levels
Operational — running normally. Degraded — elevated latency or partial errors. Outage — a component is unavailable. Maintenance — planned work, announced in advance where possible.
Incident communication
During an incident we post an initial update quickly, then at least every 30 minutes until resolution, followed by a post-incident review for outages. Updates appear here and at status.mailframe.ai.
Programmatic checks
Automate your own probes against GET /health, which returns 200 when the parse pipeline is accepting traffic.

Incident update template

The format we use when communicating an incident, from first acknowledgement through resolution:

example timeline
[ POSTED 14:02 UTC ] Investigating
We are investigating elevated error rates on POST /v1/parse. Parses may
return 5xx or be delayed. Next update within 30 minutes.

[ POSTED 14:21 UTC ] Identified
Cause identified — a bad deploy to the parse engine. Rolling back now.

[ POSTED 14:38 UTC ] Monitoring
Rollback complete; error rates back to normal. Monitoring before resolving.

[ POSTED 15:05 UTC ] Resolved
The incident is resolved. Total impact: ~36 min of elevated errors on
/v1/parse. A post-incident review will follow within five business days.

Building on MailFrame?

Read the docs to integrate the API, or check the health endpoint from your own monitoring.