Skip to main content
Version: 1.2

Sending alerts to ToBeAlert

Overview​

ToBeAlert provides a simple REST API for sending alerts from any monitoring system, application, or custom script. This guide covers everything you need to know about sending alerts, including required fields, optional attributes, and advanced features like links and tagged values.

Authentication​

All API requests must include an API key in the Authorization header:

Authorization: Key YOUR_API_KEY_HERE

For detailed information on how to create, manage, and use API keys, see the API Keys documentation.

Endpoint​

POST /api/alert
Content-Type: application/json
Authorization: Key YOUR_API_KEY

Required fields​

These fields are mandatory for all alerts based on the Alert model validation:

FieldTypeDescriptionExample
resourceStringThe resource affected by the alert"web-01.example.com"
eventStringType of event that triggered the alert"ServerDown"

Note: The id field is automatically generated if not provided. Do not include it unless you need to specify a particular ID.

Optional fields​

FieldTypeDefaultDescriptionExample
environmentString"" (empty string)Environment where the alert originated"production"
severityString"normal"Alert severity level"critical"
textString"" (empty string)Human-readable description of the alert"Server is not responding"
serviceArray[] (empty array)List of related services["web-service", "api"]
groupString"Misc"Organizational group"infrastructure"
valueStringnullMetric value"503"
tagsArray[] (empty array)Tags for categorization["linux", "production"]
attributesObject{} (empty object)Custom key-value pairsSee below
originStringAuto-generatedServer that sent the alert"nagios"
source_idStringnullApplication that sent the alert"app-monitor"
typeString"Event"Alert type"exceptionAlert"
correlateArray[] (empty array)Events to correlate with["cpu-high", "memory-low"]
timeoutIntegerFrom configAlert timeout in seconds300
raw_dataStringnullOriginal raw data"Raw alert data"
minutes_delayedIntegernullMinutes to delay the alert15
delayed_untilStringnullISO datetime to delay until"2025-04-15T14:00:00Z"
resource_parentStringnullParent resource"web-cluster-01"

Database schema notes​

From the database schema and model:

  • id is auto-generated as UUID if not provided
  • resource and event are the only truly required fields (validated in Alert.init)
  • All other fields have sensible defaults as shown above
  • severity defaults to "normal" (Severity.Normal)
  • origin defaults to script name/hostname if not provided
  • attributes is stored as JSONB for efficient querying
  • minutes_delayed and delayed_until are used for alert scheduling
  • Fields in invalidCreateColumns are automatically removed from requests

Severity levels​

LevelTextDescription
0securitySecurity-related alerts
1criticalCritical issues requiring immediate attention
2majorMajor problems affecting functionality
3minorMinor issues with limited impact
4warningWarnings about potential problems
5indeterminateIssues with undetermined severity
6informationalInformational alerts, no action required
7normalNormal operation (ok/cleared)
8debugDebug-level information
9traceDetailed trace information
10unknownUnknown severity level

Alert attributes​

The attributes field is a powerful way to add custom context to your alerts. It accepts any key-value pairs and supports special data types.

Basic attributes​

"attributes": {
"cpu_usage": "95.2%",
"memory_free": "256MB",
"error_code": "HTTP_503",
"region": "us-west-2"
}

ToBeAlert automatically detects and makes URLs clickable in alert attributes. The frontend supports three different link formats:

Format 1: Simple string URLs​

"attributes": {
"dashboard": "https://grafana.example.com/d/abc123",
"runbook": "https://wiki.example.com/runbooks/server-down"
}

Format 2: Simple object with title and URL​

"attributes": {
"links": {
"title": "Grafana Dashboard",
"url": "https://grafana.example.com/d/abc123"
}
}

Format 3: Array of objects with title and URL​

"attributes": {
"links": [
{
"title": "Grafana Dashboard",
"url": "https://grafana.example.com/d/abc123"
},
{
"title": "Runbook",
"url": "https://wiki.example.com/runbooks/server-down"
},
{
"title": "Logs",
"url": "https://logs.example.com/search?q=server-down"
}
]
}

Supported URL formats:

  • HTTP/HTTPS URLs starting with http:// or https://
  • URLs starting with www. are automatically converted to https://
  • Links open in a new tab when clicked

Recomendations for links:

  • Use descriptive titles in object format for better UX
  • Include relevant monitoring dashboards
  • Add runbook links for troubleshooting procedures
  • Provide direct links to logs or traces

Array attributes​

For multiple values:

"attributes": {
"affected_servers": ["web-01", "web-02", "web-03"],
"error_codes": ["HTTP_503", "TIMEOUT", "CONN_REFUSED"]
}

Tagged values​

Add tags to values for enhanced filtering and visualization:

"attributes": {
"status": "degraded#danger",
"priority": "high#warning",
"component": "database#danger"
}

Format: value#tag - the tag appears as a colored badge in the UI.

Array with tagged values​

"attributes": {
"components": ["database#danger", "cache#warning", "web#ok"],
"services": ["auth#production", "payment#production", "analytics#staging"]
}

Complete examples​

Basic server alert​

Basic server alert example

curl -X POST "http://your-tobealert.com:9000/api/alert" \
-H "Content-Type: application/json" \
-H "Authorization: Key YOUR_API_KEY" \
-d '{
"resource": "web-01.example.com",
"event": "ServerDown",
"environment": "production",
"severity": "critical",
"text": "Server web-01 is not responding",
"service": [
"web-service"
],
"group": "infrastructure",
"origin": "nagios",
"attributes": {
"ip_address": "10.0.1.100",
"last_check": "2025-04-15T10:30:00Z",
"dashboard_url": "https://grafana.example.com/d/server"
}
}'

Application error with links to logs and runbook

curl -X POST "http://your-tobealert.com:9000/api/alert" \
-H "Content-Type: application/json" \
-H "Authorization: Key YOUR_API_KEY" \
-d '{
"resource": "payment-service-02",
"event": "ApplicationException",
"environment": "production",
"severity": "major",
"text": "Database connection pool exhausted in payment service",
"service": [
"payment-service",
"api-gateway"
],
"group": "backend",
"origin": "application",
"attributes": {
"error_count": "150",
"pool_size": "20",
"active_connections": "20",
"logs_url": "https://logs.example.com/search?q=payment-service",
"runbook": "https://wiki.example.com/runbooks/db-pool-exhausted",
"component": "database#danger",
"affected_endpoints": [
"/api/v1/pay",
"/api/v1/validate"
]
}
}'

Cloud infrastructure alert​

Cloud infrastructure alert with AWS monitoring links

curl -X POST "http://your-tobealert.com:9000/api/alert" \
-H "Content-Type: application/json" \
-H "Authorization: Key YOUR_API_KEY" \
-d '{
"resource": "i-1234567890abcdef0",
"event": "HighCPUUtilization",
"environment": "production",
"severity": "warning",
"text": "EC2 instance CPU usage above threshold",
"service": [
"web-tier"
],
"group": "cloud-infrastructure",
"origin": "cloudwatch",
"tags": [
"aws",
"ec2",
"cpu"
],
"value": "87.5%",
"attributes": {
"instance_type": "t3.medium",
"region": "us-west-2",
"availability_zone": "usw2a",
"cpu_threshold": "80%",
"cloudwatch_url": "https://console.aws.amazon.com/cloudwatch/home?region=us-west-2",
"instance_url": "https://console.aws.amazon.com/ec2/v2/home?region=us-west-2#Instances:instanceId=i-1234567890abcdef0",
"metrics": [
"cpu#high",
"memory#normal",
"disk#normal"
]
}
}'

Response format​

Success response​

{
"status": "ok",
"id": "generated-alert-id",
"alert": {
"id": "generated-alert-id",
"href": "http://your-tobealert.com:9000/alert/generated-alert-id"
}
}

Error response​

{
"status": "error",
"message": "Invalid severity level: 'invalid'",
"errors": [
{
"field": "severity",
"message": "Must be one of: critical, major, minor, warning, etc."
}
]
}

Best practices​

  1. Use descriptive alert IDs - Include service/resource information for easier tracking
  2. Provide context in attributes - Include URLs to dashboards, runbooks, and related systems
  3. Use consistent naming - Standardize environment, service, and group names across alerts
  4. Include relevant links - Add dashboard URLs, runbook links, and troubleshooting resources
  5. Use tagged values - Leverage tagging for visual indicators in the UI
  6. Set appropriate severity - Use severity levels consistently to avoid alert fatigue
  7. Add meaningful tags - Use tags for easy filtering and categorization

Troubleshooting​

Common issues​

  1. 401 Unauthorized - Check your API key is valid and properly formatted
  2. 400 Bad Request - Verify required fields are present and correctly formatted
  3. 429 Too Many Requests - You've hit the rate limit, implement backoff
  4. Links not clickable - Ensure URLs start with http:// or https://

Validation rules​

  • Only resource and event are validated as mandatory
  • timeout: Must be a non-negative integer
  • attribute keys: Cannot contain . or $ characters (validated in Alert.init)