> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mythic-c2.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Alerts

## Agent generated alerts

Sometimes you want your agent to be able to bring something to the operator's attention. Your task might return an error, but if it's a long-running task, then who knows if the operator is actively looking at the task.

### alerts

Using the `alerts` keyword, agents can sent alert messages to Mythic's operation event log. There are two ways you can do this:

#### As part of a task

As part of a task, you can use another keyword, `alerts` to send the following structure:

```json theme={"system"}
"responses": [
    {
        "task_id": "some uuid here",
        "alerts": [
            {
                "source": "source of this message", //optional
                "alert": "the alert message you want to send to mythic",
                "level": "info", // optional level of severity for the alert - info, warning, debug, api, defaults to warning
                "send_webhook": true, // optional (default false) to indicate that you want to send a webhook alert for this anyway
                "webhook_alert": { // optional json field of the data to send along with an alert if you want more structured context
                    "some": "data"
                }
            }
        ]
    }
]
```

You can send multiple alerts at once since it's an array.

<Note>
  The `source` field doesn't get displayed to the user, but it is used to collapse like-messages within the UI. If the user has an alert that's not resolved with a source of "bob", then the next message with a source of "bob" will **NOT** be displayed, but will instead simply increase the count of the current message. If the user resolves the message with a source of "bob" and a new one comes in, then that message **WILL** be displayed. This is to help prevent users from getting flooded with messages.
</Note>

<Info>
  The "squishing" of alert messages only happens in the UI - if you have a webhook container and are listening for alerts, you will get *all* of the messages. The `basic_webhook` container has code in it to throttle alert messages of the same source though that they must be a minute apart (again, to help prevent spam to users)
</Info>

#### Not as part of a task

Sometimes you have other aspects to your agent that might be monitoring or running tasks and you want to report that data back to the user, but you don't have a specific task to associate it with. In that case, you can do the exact same `alerts` structure, but at a higher level in the structure:

```json theme={"system"}
{
    "action": "get_tasking", // any action
    "alerts": [
            {
                "source": "source of this message", //optional
                "alert": "the alert message you want to send to mythic",
                "level": "info", // optional level of severity for the alert - info, warning, debug, api, defaults to warning
                "send_webhook": true, // optional (default false) to indicate that you want to send a webhook alert for this anyway
                "webhook_alert": { // optional json field of the data to send along with an alert if you want more structured context
                    "some": "data"
                }
            }
        ]
}
```

* `send_webhook` - normally, if the `level` is not provided or is `warning` then an `alert` webhook is sent. However, if you set the level to something like `info` or `debug`, then you can optionally still force a webhook with this flag
* `level` - this identifies how `alert` is presented to the user. `warning` is the default and will show a warning error as well as put a warning notification in the event log (increasing the warning count in the UI by 1). `info` is similar - it displays an informative message in the UI to the user and adds a message to the event log, but it isn't a warning message that needs to be addressed. `debug` will allow you to send a message to the event log, but it will *not* display a toast notification to the user.
* `alert` - your normal string message that's displayed to the user and put in the event log
* `webhook_alert` - optional dictionary data that doesn't get displayed to the user or put in the operation event log, but is instead sent along as custom data to the `custom_webhook` webhook for additional processing. Specifically, the data sent to the `custom_webhook` is as follows:

The following is an example of the data you have available as part of a webhook alert. You can see the default fields, but your `webhook_alert`, `source`, and `alert` string are all also passed in.

```python webhook alert message format theme={"system"}
if err := RabbitMQConnection.EmitWebhookMessage(WebhookMessage{
	OperationID:      operationInfo.ID,
	OperationName:    operationInfo.Name,
	OperationWebhook: operationInfo.Webhook,
	OperationChannel: operationInfo.Channel,
	OperatorUsername: "",
	Action:           WEBHOOK_TYPE_CUSTOM,
	Data: map[string]interface{}{
		"callback_id":   callbackID,
		"alert":         alert.Alert,
		"webhook_alert": alert.WebhookAlert,
		"source":        alert.Source,
	},
}); err != nil {
	logging.LogError(err, "Failed to send webhook")
}
```