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
Observability Cloud
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
Platform overview

Quickstart

Go from zero to confident with Axiom. Learn datasets, queries, virtual fields, monitors, and dashboards in progressive steps.

This guide takes you from foundational knowledge to advanced proficiency with Axiom. The sections are structured to build upon one another but can also serve as standalone references. By the end, you can independently query data, diagnose performance, derive insights, and set up proactive alerting.

Axiom fundamentals

Axiom is the modern machine data platform. Machine data is any record a system produces: logs, distributed traces, metrics, and events like product analytics, marketing attribution, or security audit trails. Axiom stores and queries all of it through one engine.

Datasets store related machine data, similar to a table in a traditional database. For example, the Axiom Playground includes datasets like sample-http-logs for HTTP request logs and github-push-event for GitHub activity.

Fields are named pieces of data on each record, like columns in a spreadsheet. Fields have a name (for example, status, resp_body_size_bytes, geo.city) and a value. Axiom supports various data types including strings, numbers, booleans, and complex JSON objects.

When to split a dataset
  • Single dataset: Use one dataset when events share many common fields and you often query them together.
  • Multiple datasets: Split into multiple datasets when the data is structurally different or serves entirely different use cases. This prevents a single dataset from accumulating fields that are only relevant to a small subset of its events.

Send data to Axiom

You can send your first event with a single HTTP request:

shell
curl -X 'POST' 'https://AXIOM_DOMAIN/v1/ingest/DATASET_NAME' \
    -H 'Authorization: Bearer API_TOKEN' \
    -H 'Content-Type: application/x-ndjson' \
    -d '{ "http": { "request": { "method": "GET", "duration_ms": 231 }, "response": { "body": { "size": 3012 } } }, "url": { "path": "/download" } }'
Info

Replace AXIOM_DOMAIN with the base domain of your edge deployment. For more information, see Edge deployments.

Replace API_TOKEN with the Axiom API token you have generated. For added security, store the API token in an environment variable.

Replace DATASET_NAME with the name of the Axiom dataset where you send your data.

To send events continuously, Axiom supports a wide range of tools and libraries:

  • OpenTelemetry for industry-standard instrumentation of traces, logs, and metrics.
  • Axiom API for direct HTTP ingestion from any language or platform.
  • Language libraries for JavaScript, Python, Go, Rust, .NET, and more.
  • Log shippers like Vector, Fluent Bit, and Logstash.
  • Platform integrations for AWS, Kubernetes, Vercel, and Cloudflare Logpush.

For the full list, see Methods for sending data.

Explore your data

Start by identifying the correct dataset in the Datasets tab. You can explore the fields within a dataset to find relevant information. For example, in sample-http-logs you might look at resp_header_size_bytes (response size), status (HTTP status code), and geo.country (geographic origin).

Idea

Pay attention to field data types. A field stored as a number behaves differently than one stored as a string. The schema view in the Datasets tab shows the type for each field.

Build your first queries

You typically interact with this data by creating queries using one of the following interfaces:

  • Builder: A point-and-click interface that helps you build filters and aggregations without writing code. It's excellent for simple, quick-look analyses.
  • Editor: An interface where you can write queries using powerful, text-based query languages for sophisticated analysis. Use APL (Axiom Processing Language) for logs, traces, and events, and MPL (Metrics Processing Language) for metrics.
  • Axiom API: Query your data programmatically.
  • AI-assisted query building: Generate APL queries from natural language descriptions after pressing Cmd+K (macOS) or Ctrl+K (Windows/Linux) in the Query tab.
  • MCP Server and Skills: Enable AI agents to query your data. Agents without an existing organization can provision their own temporary organization.

An APL query starts with a data source, followed by operators connected by the pipe | character. Each pipe takes the output of the previous line and uses it as input for the next, allowing you to chain operations. A common pattern is dataset, filter (where), transform (extend), analyze (summarize).

This example counts distinct users per day, grouped by HTTP method:

APLRun in Playground
['sample-http-logs']
| summarize dcount(id) by bin(_time, 1d), method
  • ['sample-http-logs'] selects the dataset.
  • | passes the data to the next operator.
  • summarize groups rows that share values in the by clause.
  • dcount(id) calculates the distinct count of the id field. This is a probabilistic function that provides a highly accurate approximation and runs faster than an exact count.
  • by bin(_time, 1d), method groups by time binned into 1-day intervals and by HTTP method.
Idea
  • Start with Builder to understand the basic structure of a query, then switch to Editor to refine it.
  • Use the AI assistant as a learning tool. Generate a query and then study its structure to understand the APL.
  • Use the where operator early to narrow down events. This is important for performance.
  • Review your team's saved queries in Axiom to learn from real-world examples.
  • The full list of functions and operators is available in the Query reference.

Set up monitors

Monitors run queries on a schedule and trigger notifications when conditions are met. This moves you from reactive investigation to proactive awareness.

  • Threshold monitors trigger when an aggregated value crosses a threshold (for example, error counts above 100 in 5 minutes). This is the most common type.
  • Match monitors trigger for each individual event that matches a specific pattern (for example, a critical error message). Use these sparingly for high-volume events.
  • Anomaly monitors use machine learning to detect unexpected deviations from a historical baseline, without a static threshold.

This example creates a threshold monitor to get a notification if the number of server errors exceeds a threshold.

  1. Write and test the query:

    APL
    ['sample-http-logs']
    | where status >= 500
    | summarize error_count = count()
  2. Go to Monitors tab and create a new threshold monitor.

  3. Paste your query and set the trigger condition, for example, When error_count is above 50.

  4. Set the schedule, for example, evaluate every 5 minutes.

  5. Select or create a notifier (Slack, PagerDuty, email, and more).

Idea
  • Customize the notifier description to include important context such as a link to a relevant dashboard.
  • Avoid creating match monitors on high-volume logs without specific filters. This can lead to excessive notifications.

Build dashboards

Dashboards are collections of saved queries visualized as charts, tables, and other elements. They provide a single view for monitoring a service, tracking an experiment, or sharing key metrics.

This example creates a dashboard to monitor HTTP request performance.

Element 1: P75 and P95 latency (time series)

This query calculates the 75th and 95th percentiles of request duration and displays them as a time series.

APLRun in Playground
['sample-http-logs']
| summarize
    P75 = percentile(req_duration_ms, 75),
    P95 = percentile(req_duration_ms, 95)
  by bin_auto(_time)

Element 2: Requests by country (table)

This query counts the number of requests by country and displays them as a table.

APLRun in Playground
['sample-http-logs']
| summarize request_count = count() by ['geo.country']
| sort by request_count desc

Element 3: Total distinct users (statistic)

This query counts the number of distinct users and displays them as a statistic.

APLRun in Playground
['sample-http-logs']
| summarize dcount(id)
Idea
  • Give dashboards and their elements clear, descriptive names.
  • Use dashboard filters to allow viewers to slice data by dimensions like region, status code, or service.
  • Avoid cluttering a single dashboard with unrelated metrics. Create separate dashboards for different use cases.

What's next

  • APL introduction for the full query language reference.
  • Sample queries for real-world APL examples you can run in the Playground.
  • Send data to Axiom to connect your own data sources.
  • Monitor examples for more alerting patterns.
Was this page helpful?
Suggest edits on GitHub
PreviousWhat is Axiom?NextArchitecture
On this page
Axiom fundamentalsSend data to AxiomExplore your dataBuild your first queriesSet up monitorsBuild dashboardsWhat's next