​

Graylog Threshold Alerts

​

Overview

​

When to use threshold alerts

• Brute-force / credential stuffing — e.g., ≥ 10 failed authentication attempts within 5 minutes for the same user or source IP.
• Excessive privilege escalation attempts — e.g., ≥ 5 sudo failures on a single host in 10 minutes.
• Anomalous volume — e.g., ≥ 100 Office 365 FileDeleted events from the same user in 15 minutes.
• Repeated policy violations — e.g., ≥ 3 DLP policy hits from the same endpoint in 1 hour.
• Scan / enumeration detection — e.g., ≥ 50 connection attempts to different ports on the same destination in 1 minute.

Rule of thumb: If the detection logic includes words like “more than,” “at least,” or “within X minutes,” you likely need a threshold alert.

​

Step-by-step configuration

​

1. Create the Event Definition in Graylog

1. Navigate to Alerts → Event Definitions in the Graylog web UI.
2. Click Create Event Definition.
3. Fill in the Title and Description — this title will become the alert name inside CoPilot.

​

Condition Configuration

4. Under Condition Type, select Filter & Aggregation.
5. Define your search query (filter) to match the relevant log events (e.g., source:office365 AND event_type:login_failure).
6. Set the Search within time window (e.g., 5 minutes).
7. Set the Execute search every interval (e.g., 1 minute).
8. Under Aggregation, configure:
   • Group By — the field(s) to group on (e.g., source_ip, username, agent_name).
   • Condition — e.g., count() >= 10.

⚠️ Make sure the aggregation condition accurately reflects the threshold you want. Test with Preview before saving.

​

2. Define the required Custom Fields

• Set a static value (e.g., CUSTOMER_CODE = ACME) if this event definition is customer-specific, or
• Use a template that references Graylog event fields (e.g., ASSET_NAME = ${source.agent_name}).

CUSTOMER_CODE  →  ACME
SOURCE         →  office365
ALERT_DESCRIPTION → Excessive login failures detected (threshold: 10 in 5 min)
ASSET_NAME     →  ${source.agent_name}

🚨 IMPORTANT: Do NOT add a field called COPILOT_ALERT_ID with a value of NONE. This will break the auto-alert creation functionality for standard (non-threshold) alerts.

​

3. Create the HTTP Notification

1. Navigate to the Notifications tab of your Event Definition (or go to Alerts → Notifications → Create Notification).
2. Select HTTP Notification as the notification type.

🚨 IMPORTANT: Use the standard HTTP Notification type — do NOT use the Custom HTTP Notification type. The custom type sends a different payload format that CoPilot cannot parse.

3. Configure the notification:

4. Save the notification.

​

4. Attach the Notification to the Event Definition

1. Go back to your Event Definition → Notifications tab.
2. Click Add Notification and select the HTTP Notification you just created.
3. Save the Event Definition.

​

5. Verify the Graylog API header

​

The SOURCE field and index resolution

​

Why CoPilot needs a mapping

This is not the same as the ingest-side Incident Sources mapping. Those describe per-source field names; this maps a SOURCE value to the physical index a threshold replay query should target.

​

How a SOURCE is resolved

1. .env mapping (THRESHOLD_SOURCE_INDEX_MAPPING) — explicit, operator-defined mappings. Highest priority.
2. Built-in defaults — wazuh → wazuh-* and office365 → office365-*, shipped out of the box.
3. Convention fallback — for any other SOURCE, CoPilot derives <source>-* with a timestamp time field. So a SOURCE of bitwarden automatically resolves to the bitwarden-* index with no configuration required, as long as your index follows the <source>-* naming convention.

​

Configuring custom sources (.env)

# Simple: SOURCE "bitwarden" -> index "bw-logs-*" (time field defaults to "timestamp")
# Advanced: SOURCE "dellswitch" -> index "dellswitch-*" with a custom time field
THRESHOLD_SOURCE_INDEX_MAPPING={"bitwarden": "bw-logs-*", "dellswitch": ["dellswitch-*", "@timestamp"]}

After changing these variables, restart the CoPilot backend so the new configuration is picked up.

​

How it works end-to-end

┌─────────────┐     threshold met      ┌─────────────────────┐
│   Graylog   │ ─────────────────────▶  │  HTTP Notification  │
│  Event Def  │   (count ≥ N in T)      │  (standard type)    │
└─────────────┘                         └─────────┬───────────┘
                                                  │
                                        POST /api/incidents/alerts/create/threshold
                                                  │
                                                  ▼
                                        ┌─────────────────────┐
                                        │      CoPilot        │
                                        │  Incident Mgmt      │
                                        │  (new alert created) │
                                        └─────────────────────┘

1. Graylog evaluates the aggregation query on schedule (e.g., every minute).
2. When the threshold condition is met, Graylog fires the Event Definition.
3. The HTTP Notification sends a POST request to CoPilot’s /create/threshold endpoint with the event payload (including your custom fields).
4. CoPilot validates the Graylog header, extracts the required fields (CUSTOMER_CODE, SOURCE, ALERT_DESCRIPTION, ASSET_NAME), and creates a new alert in Incident Management.
5. The alert appears in the CoPilot Incident Management → Alerts view and can be triaged, assigned to a case, or trigger downstream automation (e.g., via Shuffle).

​

Differences from standard alerts

​

Troubleshooting

​

Related pages

• Alerting → Shuffle (notifications & automation)
• Alerts — SIEM view
• Graylog Management (detections)
• Incident Management
• Incident Alerts
• Incident Sources (mapping context)