Performance Methodology

This page defines every performance metric published by ApexMail, including how it is measured, the measurement period, geographic coverage, exclusions, and limitations. Every publicly displayed performance number must link to its definition on this page or to the relevant section below.

The three canonical latency labels used across the site are:

1. Production API SLA: P95 ≤ 500ms measured at gateway — contractual SLA metric for Enterprise plans, measured server-side at the API gateway.
2. Sandbox validation target: typically under 120ms — guidance target for sandbox/test-mode validation latency; no email is sent.
3. Private Cloud illustrative: architecture-dependent, not an SLA — deployment-specific; contractual Private Cloud latency targets are defined per-deployment in customer agreements.

1. Delivery Metrics

“Delivery rate” must never appear without a specific definition. The following metrics are the only permitted public delivery measurements.

1.1 API Acceptance Rate

Definition: The percentage of valid API requests that are accepted for processing within a measurement period.

1.2 Processing Success Rate

Definition: The percentage of accepted messages that are successfully processed by the ApexMail delivery pipeline and handed off to the recipient’s mail server or queued for delivery.

1.3 Recipient-Server Acceptance Rate

Definition: The percentage of delivery attempts that result in a successful handoff to the recipient’s mail server, measured after all retries are exhausted.

1.4 Inbox Placement

ApexMail does not measure or publish inbox placement rates as a service-level metric. Inbox placement is determined by the recipient’s mail provider, which ApexMail does not control. Statements implying inbox placement guarantees or measurement must not be made. Inbox placement testing via seed lists is available as a product feature on qualifying plans; seed results do not guarantee recipient-wide placement.

2. Latency Metrics

2.1 Production API Latency (SLA Metric)

This is the contractual SLA metric for Enterprise plans: Production API SLA: P95 ≤ 500ms measured at gateway.

Any published API latency number must specify the exact measurement boundaries.

Permitted public statement example:

Production API SLA: P95 ≤ 500ms measured at gateway — measured server-side over a rolling 30-day period for all authenticated requests in the EU region.

Prohibited statements:

Average API latency is under Xms. (Must specify p50/p95/p99 — “average” is ambiguous.)

API responds in under Xms. (Must specify what start and end events measure and exclude network round-trip.)

2.2 Sandbox Validation Latency (Guidance)

Sandbox validation target: typically under 120ms. This is a guidance target, not an SLA.

2.3 Queue-Processing Latency

2.4 First-Delivery-Attempt Latency

2.5 End-to-End Delivery Latency

Permitted public statement example:

End-to-end delivery latency: p95 is under X seconds, measured from API acceptance to SMTP handoff, including retry delays, over a rolling 30-day period.

2.6 Webhook Latency

2.7 Private Cloud Latency

Private Cloud illustrative: architecture-dependent, not an SLA. Private Cloud latency is deployment-specific and depends on customer region, network topology, VPC configuration, and proximity between the customer’s application and the ApexMail API infrastructure. Contractual Private Cloud latency targets are defined per-deployment in the customer agreement.

Public-facing Private Cloud latency comparisons are illustrative scenarios only, not performance guarantees.

2.8 Measurement Notes

• “Under 1.2 seconds” must specify exactly what it measures and at what percentile.
• Mean and median are not used interchangeably.
• All measurements include the measurement period.
• Sandbox, production, and Private Cloud latencies are not the same metric and must not be conflated.

3. Uptime and Availability

3.1 Component Definitions

Uptime is measured per component, not as a single global number. Each component has its own availability calculation.

3.2 Calculation Rules

3.3 SLA vs. Historical Availability

• SLA (Service Level Agreement): A contractual commitment to a minimum uptime percentage over a billing period. Defined per plan in the customer agreement. Not displayed as a general number on the website.
• Historical availability: The actual measured uptime over a past period (displayed on the status page). This is descriptive, not prescriptive.
• The status page displays historical availability only. SLA commitments are documented in customer agreements, not on the public status page.

4. Monitoring Systems

Probe Locations

5. Exclusions

The following are excluded from performance calculations:

• Test traffic: Messages sent to test domains, sandbox environments, or internal test recipients.
• Customer misconfiguration: Failures caused by missing DNS records (SPF, DKIM, DMARC), unverified domains, or incorrect API key usage.
• Recipient issues: Full mailbox, invalid recipient address, recipient server policy rejection — counted in bounce metrics, not performance metrics.
• Force majeure events: Events qualifying as force majeure under the Terms of Service (natural disasters, internet backbone failures, DDoS attacks exceeding mitigation capacity).
• Scheduled maintenance: Published maintenance windows with at least 48 hours’ notice.

6. Data Quality Limitations

• Probe-based measurements may miss transient failures shorter than the probe interval (in minutes).
• SMTP probe success does not guarantee every customer’s SMTP connection succeeds; it verifies that the SMTP service is operational from the probe locations.
• Internal metrics (queue depth, worker count) are self-reported and may lag up to 15 seconds.
• Geographic coverage is limited to EU probe locations. Customers accessing from other regions may experience different network latency.
• Recipient-server acceptance rates are affected by recipient policies, reputation, and blocklists, which are partially outside ApexMail’s direct control.

7. Methodology Changes

When methodology changes would materially affect published numbers:

• The previous methodology’s numbers are archived.
• A notice is published on the status page and in the changelog.
• The new methodology is versioned and the old version remains accessible for at least 12 months.

8. Update Schedule

9. Contact

Questions about performance methodology: support@apexmail.ee Report discrepancies in published metrics: support@apexmail.ee Security concerns: security@apexmail.ee