Docs
DocumentationQuery ReferenceAPI Reference
Open Console→→
DocumentationQuery ReferenceAPI Reference

Platform overview

What is Axiom?QuickstartArchitectureFeatures
Fundamentals
Datasets
Edge deployments
Limits
Performance
Optimize usage
Requirements
Semantic conventions
Glossary
Tour
SecurityRoadmap

Send data

Reference architecturesMethods

Understand data

Console
Query
Builder
Editor
Query results
Visualize
Traces
Metrics
Correlations
Save queries
Stream
Dashboard
Create
Elements
Create
Configure
Element types
Gauge
Heatmap
Log stream
Monitor list
Note
Pie chart
Scatter plot
Statistic
Table
Time series
Sections
Configure
Filter
Annotate
Monitor
Overview
View status
Configure
Examples
Monitor types
Anomaly
Match
Threshold
Alerting
Overview
Configure
Notifier types
Custom Webhook
Discord
Email
Microsoft Teams
Opsgenie
PagerDuty
Slack
Manage
Datasets
Overview
Views
Virtual fields
Access
RBAC
Tokens
CLI
Organization
Audit log
Settings
Usage and billing
Profile
Extend
Overview
AWS Lambda
AWS PrivateLink
Cloudflare Workers
Cloudflare Logpush
Convex
Grafana
Hex
Netlify
Supabase
Tailscale
Terraform
Vercel
Intelligence
Overview
Spotlight
AI agents
Overview
MCP Server
Query cost limits
Agent-created orgs
Skills
Overview
Axiom alerting
Build dashboards
Control costs
Query metrics
SRE
Translate SPL to APL
Splunk
Overview
Splunk app
Install and configure
Commands
Examples
Splunk Portal
How it works
Set up standard mode
Set up transparent mode
SPL command support
Examples
Monitor and troubleshoot

Use cases

ObservabilityProduct analytics
LLM observability
Overview
Use Axiom AI SDK
Manual instrumentation
GenAI attributes
Redaction policies

Miscellaneous

LLMs
Overview
List of docs pages
Full docs
Query reference
FAQs
Legal
Acceptable use policy
Cookies
Data processing
HIPAA
Privacy policy
SLA
Terms of service
Terms of use
Miscellaneous/Legal

SLA

Building event data infrastructure your team can trust.

Axiom is committed to delivering a reliable, performant, and secure data platform. We want our customers to have full confidence in the Axiom Service, backed by transparent commitments. This Service Quality document covers:

  1. Service availability and corresponding SLAs
  2. Priorities, support response times, and escalation
  3. Incident management and communications

Please note this Axiom Service Quality document is subject to the agreement between Customer and Axiom with respect to the Axiom Service (the “Agreement”). All terms not otherwise defined herein are defined as set forth in the Agreement.

Service availability

Scope

This Axiom Service Level Agreement (“SLA”) describes the service availability regarding the Axiom Service specified in the applicable Service Description or otherwise ordered by Customer. This SLA applies to the core functionality of the applicable Axiom Service: components such as data ingestion, query execution, alerting, and access to the Axiom Console and API; it does not apply to preview features unless otherwise noted herein.

Availability commitments

Axiom provides the following target uptime (the “Monthly Uptime Percentage” or “MUP”) with respect to Axiom Cloud:

Axiom ServiceMonthly Uptime Percentage
Axiom CloudAt least 99.9% (“three nines”)

Axiom measures MUP on a calendar-month basis by taking the total minutes in a calendar month, subtracting any Scheduled Downtime and Exclusions, and then calculating how many of the remaining minutes the Axiom service was available.

Scheduled and unscheduled downtime

  • Scheduled Downtime: means the maintenance windows that Axiom communicates to Customer at least seven (7) days in advance. Axiom strives to limit Scheduled Downtime to three (3) hours per month.

  • Unscheduled Downtime: means any period of time the Axiom Service is unavailable, other than Scheduled Downtime or Exclusions. For example, system failures, unplanned service degradations, or regional outages.

  • Exclusions: means any of the following:

    • emergency maintenance;
    • circumstances or events beyond the reasonable control of Axiom, including without limitation, any Force Majeure events;
    • the performance or availability of local internet-service-providers engaged by Customer, and outages directly traceable to external providers (e.g., cloud platforms, DNS);
    • issues resulting from Customer’s use of third-party hardware, software, or systems, network, firewalls, or infrastructure preventing normal Axiom usage;
    • use by Customer of the Axiom Service not in strict compliance with the applicable Documentation;
    • incidents caused by misuse, negligence, or unapproved modifications of Axiom Services;
    • Unscheduled Downtime with respect to any Axiom Service made available on a no-fee or trial basis, or for which Customer has not paid to Axiom all of the applicable fees;
    • Services clearly labelled “Preview”; and
    • any issues resulting from changes to a Customer’s configuration of the Axiom Service.

“Incident” means a failure to meet the applicable MUP due to Unscheduled Downtime.

Service credits

If an Incident occurs with respect to Axiom Service , Customer may request credits with respect to such Axiom Service (“Credits”). To receive Credits, Customer must meet the following requirements:

  • Notify the Axiom support team within thirty (30) days of the date the Incident occurred with the following phrase in the title: “SLA Incident” (the “Notice”);

  • Notice must include: logs and supporting information reasonably necessary for Axiom to confirm the SLA Issue; and dates and times with respect to the SLA Issue.

Once verified by Axiom, Credits will be issued as a percentage of Customer’s monthly (or prorated) bill for the affected Axiom Service. Customer acknowledges and agrees that notwithstanding anything to the contrary: (a) the Credit is the sole and exclusive remedy with respect to any SLA Issue; (b) the Credit may only be used by Customer to reduce the applicable monthly fees with respect to future payment obligations regarding the Axiom Service impacted by the Incident; (c) Credits may not be converted into cash, cash equivalents, or entitle Customer to a refund; (d) any unused Credits shall expire and be of no use following the expiration or termination of the applicable Service Order or the Agreement; and (e) Credits may not be used to reduce the applicable monthly fees by more than fifty percent (50%).

The table below shows how Credits are calculated:

Monthly Uptime PercentageService Credit Percentage
Axiom Cloud: < 99.9% but >= 99.0%10%
Axiom Cloud: < 99.0% but >= 95.0%25%
Axiom Cloud: < 95.0%50%

Priorities, support response times, and escalation

Bug resolution

Axiom investigates all reported Issues. Axiom uses commercially reasonable efforts to fix or provide a workaround as set forth in this Service Quality document. If Axiom needs more time to address an Issue, Axiom will escalate internally and keep Customer informed regarding progress.

“Issue” means an incident that investigation reveals is caused by the Axiom Service’s failure to perform materially in accordance with the specifications set forth in the Documentation for such Axiom Service. An incident will not be classified as an Issue if (a) the relevant Axiom Service is not used for its intended purpose; (b) the incident is caused by Customer’s or a third party’s software or equipment; or (c) the version of the Axiom Service on which the Issue has purportedly occurred is not the most current version of such Axiom Service made available to Customer under the Agreement.

Priority levels and escalation

Axiom offers Standard and Premium support. Standard support is included for all paying customers. Premium support is available as an add-on. Axiom classifies Issues by priority, ensuring faster responses and more frequent updates for critical issues.

PriorityDescriptionStandard ResponsePremium ResponseUpdate Frequency
Critical (P1)Issue results in complete system failure or critical business process disrupted.3 hours (24x7)1 hour (24x7)Hourly
High (P2)Issue results in partial system failures or disruptions to important business processes.1 business day4 hours (24x7)Every 4 hours during business hours
Medium (P3)Issue results in minor system failures or disruptions to non-critical business processes.2 business days1 business dayWeekly
Low (P4)Issue results in minor issues or requests that do not significantly affect business operations.3 business days2 business daysOn material updates

For Critical, High, and Medium Issues that require additional attention, Axiom offers a tiered escalation process:

  1. Technical Customer Support Engineer
  2. Head of Product
  3. VP of Engineering
  4. CTO

Escalations to these levels are not automatic but are considered based on the nature and urgency and impact of the Issue. Axiom’s support team will manage this process, ensuring that the right people are involved at the right time.

Escalating a request

  • If your request is already being handled by Customer Support, reply in the existing support thread and request an escalation.
  • If you have a new request, write an email to support@axiom.co with "Escalation Request" in the subject line.

Our team monitors these channels closely and will respond promptly to escalation requests.

Business hours

Axiom Customer Support is offered during business hours as set forth below:

  • Business hours: 8:00 AM – 6:00 PM Eastern Time (US) on weekdays, excluding U.S. public holidays.
  • EU support: For EU-based requests, 8:00 AM – 6:00 PM ET on weekdays, excluding local public holidays.

Incident management and communications

Axiom continuously monitors systems and has an on-call rotation that spans multiple time zones. For real-time visibility of incidents and maintenance, visit status.axiom.co. In the event of Critical (P1) or High (P2) issues:

  1. We will post updates to status.axiom.co (at least hourly during business hours).
  2. Once resolved, we will share a post-mortem for Critical (P1) issues detailing what happened, how we mitigated the Issue, and how we plan to prevent future Issues.

An Issue will be considered resolved when one of the following has been completed:

  1. a resolution to the Issue is made available to Customer;
  2. a computer software code change in the form of a patch or a new revision that corrects the Issue is made available to Customer;
  3. a short-term workaround is made available to Customer; or
  4. an engineering commitment is made to correct the Issue in a future release of the Axiom Service.

Axiom is not obligated to correct any Issue or issue that meets any of the following conditions:

  1. where the Axiom Service is not used for its intended purpose; or
  2. where the Axiom Service has been altered, damaged, modified in a manner not approved in writing by Axiom; or
  3. where the Axiom Service is a version that is no longer supported by Axiom; or
  4. which is caused by Customer’s or a third party’s software, equipment, network or system;
  5. which is caused by Customer’s negligence, abuse, misapplication, or use of the Axiom Service other than as specified in the Documentation; or
  6. which would be resolved by the Customer using an error correction or update regarding the Axiom Service.

Customer acknowledges that new features may be added to the Axiom Service based on market demand and technological innovation. Accordingly, as Axiom develops enhanced versions of the Axiom Service, Axiom may cease to maintain and support older versions.

Was this page helpful?
Suggest edits on GitHub
PreviousPrivacy policyNextTerms of service
On this page
Service availabilityScopeAvailability commitmentsScheduled and unscheduled downtimeService creditsPriorities, support response times, and escalationBug resolutionPriority levels and escalationEscalating a requestBusiness hoursIncident management and communications