Events API Object

Schema to use when posting data to the Events API

  "check": "cpu",
  "class": "server",
  "description": "CPU spike to 75%",
  "source": "",
  "service": [ "retail", "support" ],
  "severity": "Major",
  "time": 1618430099,
  "alias": "alias",
  "dedupe_key": "dedupe_key",
  "location": {
    "geo_coordinates": {  "lat":42.3665325, "long": -71.0501863 },
    "region": "us-west-1"
  "manager": "CloudWatchEC2",
  "manager_id": "1234",
  "tags": {
      "error-code" : "x0F391",
      "default-sprint": "dazzling-wright",
      "scrum-team": "spifftacular-brainiacs"
   "type" : "Capacity"

Required fields



The performance, health, or other check that triggered the event. Examples include "cpu load", "mongoDB query", and "web server response code".

If two events involve different problems on the same source and service, they should belong to different alerts. For this reason, the check field should be fairly specific. Suppose two events describe database errors on the same source : one is a replication error and another is a query error. If the check is "database" for both events, they will get deduplicated into the same alert. The better choice is to use “database-replication” for the first check and “database-query” for the second.



A human-readable description of the event. A good description summarizes the exact conditions and thresholds that triggered the event. Examples include:

  • "en0 bandwidth util > 50%"

  • "myApp response time > 1sec"

  • "myWebService 4xx https responses/sec > 20%"

  • "myService unavailable"

When Moogsoft creates or updates an alert with a new event, this description becomes the alert description.



The relative severity of the event. When you define severity levels, consider the significance of an event source if possible. A low-priority source might trigger "high-severity" events that might actually be lower-priority in the context of all your event sources.

Specify an integer or string as follows:

  • 0 — "Clear"

  • 1 — "Unknown" — Avoid this if possible, unless you need to send the specific event and you cannot determine its severity.

  • 2 — "Warning"

  • 3 — "Minor"

  • 4 — "Major"

  • 5 — "Critical"

When Moogsoft creates or updates an alert with a new event, this severity becomes the alert severity.



The server, node, or other entity that generated the event. This can be any unique, human-readable name such as a hostname, fully qualified domain name, or URL.

In some cases, a process or application might trigger an event that has no node identification. In this case, specify a unique identifier of the generating instance such as a database name, container name, or cluster node name.

Optional fields



The alias for the event source, as defined in the alias field in the event or the source field in the anomaly. You can specify aliases through ingestion or enrichment.



The high-level category of the resource that generated the fault or performance event. Examples include Application, Network, Storage, Database, and Operating System.

You can use the Classify workflow action to auto-generate the event class based on other fields in the payload.

This field determines the class field in the resulting alert. The alert class can be useful for correlating alerts into incidents. See Correlate Alerts into Incidents.

## dedupe_key


Do not include this field in your event payload unless you want to customize the default deduplication behavior. See Event deduplication: how-to and best practices.



A set of key-value pairs that specify the physical or virtual location where the event occurred.

When defining locations, it is good practice to use the same conventions for all events. For example, if you want to define virtual locations, use the same event field (such as data_center) and the same location names used by your cloud vendor.

The events schema includes the following location fields:

  • Physical locations (string) — street, building, city, state_or_province, country, postcode, rack, aisle, u_position

  • Physical location (integer) — suite, floor

  • geo_coordinates — The lat and long fields are strings. Use Decimal degrees (DD) format, for example “41.40338”, “2.17403"

  • Virtual or cloud locations (string) — region, data_center, availability_zone



A general identifier of the event generator or intermediary, such as AppDynamics, NewRelic, Nagios, Docker, RedHat, Mongo, or CloudWatchEC2.



ID for the external manager or tool that sent the alert. This field can be useful with external monitoring tools that support workflow automation: when a user closes an alert in Moogsoft, the corresponding alert can then be closed in the sending manager using this ID.



One or more applications or services that either generated the event or are associated with it. Moogsoft uses the "source", "service", and "check" fields to filter out duplicates and aggregate similar events into alerts.

You can use this tag to specify the level of event aggregation and deduplication in your alerts. For more general alerts, use general names such as "docker" or "ticket-reservation-app". For more targeted alerts, use a microservice or other specific name.


JSON object

You can include key-value pairs with additional information relevant to your users and teams.

See Tags.


UTC timestamp

You can specify the time in either seconds or milliseconds. If the payload does not include a time, Moogsoft uses the event arrival time.



The high-level category of the issue that generated the fault or performance event. Examples include Availability, Capacity, Connectivity, Security, and Activity.

You can use the Classify workflow action to auto-generate the event type based on other fields in the payload.