How Events Work
When you create an event, it appears as a vertical annotation on your Throughput and Response Time dashboard charts. This lets you visually answer questions like:- “Did error rates spike after that deploy?”
- “Did response times improve after we scaled up?”
- “When exactly did that incident start?”
Event Types
| Type | Description |
|---|---|
deployment | Code releases, deploys, rollbacks |
incident | Outages, degradations, alerts fired |
config_change | Feature flags, environment variable changes |
scale | Autoscaling events, manual scaling |
custom | Anything else you want to track |
Scoping
Events can be scoped to specific buckets and/or environments, or applied globally:["*"](default) — applies to all buckets or all environments- Specific SIDs — e.g.
["bkt_abc123"]to scope to a single bucket
["*"] appear everywhere.
Creating Events
There are three ways to create events:1. Dashboard UI
Navigate to Account → Events and click Create Event. Fill in the type, name, description, and optionally scope to specific buckets and environments.2. REST API
Send aPOST request to create events programmatically — ideal for CI/CD pipelines.
3. MCP Server
If you have an MCP token configured, AI assistants can create events using thecreate_event tool.
CI/CD Integration Examples
The most powerful use of events is automated creation from your CI/CD pipeline. Here are examples for common platforms:List Events
Retrieve events for an account, with optional filtering by type, time range, and bucket.Path Parameters
Account identifier (format:
acc_ followed by 27 alphanumeric characters)Query Parameters
Filter by event type:
deployment, incident, config_change, scale, customISO 8601 start time to filter events from
ISO 8601 end time to filter events until
Filter to events that apply to a specific bucket
Filter to events that apply to a specific environment
Maximum number of results (default: 25, max: 100)
Headers
Bearer token for authentication
Response
Indicates if there are more records to paginate through
Get Event
Retrieve details of a specific event.Path Parameters
Account identifier
Event identifier
Headers
Bearer token for authentication
Response
Returns a single event object with the same structure as described in the List Events response.Create Event
Create a new event marker.Path Parameters
Account identifier
Headers
Bearer token for authentication
Request Body
Event type:
deployment, incident, config_change, scale, customHuman-readable event name (e.g. “v2.3.1 production release”)
Longer description of the event
Source of the event (e.g.
github_actions, gitlab_ci, jenkins, manual)Freeform key/value metadata. Use this to store commit SHAs, branch names, image tags, or any other context.
Bucket SIDs this event applies to. Defaults to
["*"] (all buckets).Environment SIDs this event applies to. Defaults to
["*"] (all environments).ISO 8601 timestamp when the event started. Defaults to the current time.
ISO 8601 timestamp when the event ended. Leave null for point-in-time events (e.g. a deploy).
Response
Returns the created event object.Update Event
Update an existing event. Useful for setting theendedAt time on an incident or updating metadata.
Path Parameters
Account identifier
Event identifier
Headers
Bearer token for authentication
Request Body
All fields from the Create Event request body are accepted. Only provided fields will be updated.Response
Returns the updated event object.Delete Event
Delete an event marker.Path Parameters
Account identifier
Event identifier
Headers
Bearer token for authentication
Response
ID of the deleted event
Flag indicating the event was successfully deleted
MCP Server Access
Events are also accessible through the ApiTraffic MCP server, allowing AI assistants to create and list events:| Tool | Description |
|---|---|
list_events | List event markers with filtering by type, time range, and bucket |
create_event | Create a new event marker |
Best Practices
- Use descriptive names — Include version numbers, branch names, or ticket IDs in event names so they’re meaningful at a glance on the chart.
- Add metadata — Store commit SHAs, Docker image tags, PR numbers, and other context in the
metadatafield. This makes it easy to trace back from a traffic anomaly to the exact change. - Scope when possible — If a deploy only affects one service/bucket, scope the event to that bucket. This keeps dashboards clean and focused.
- Close incidents — When an incident is resolved, update the event with an
endedAttimestamp and a description of the resolution. - Use consistent sources — Standardize on source names like
github_actions,gitlab_ci,jenkins,manualacross your team.