Monitoring Dropzone

There are two supported patterns:

Option 1: API Pull

  • Use: /app/api/v1/system-events/list endpoint

  • Poll system-events API

  • Filter events by category (e.g., investigations, integrations, API, system info)

  • Send to SIEM

  • Map events into your SIEM/observability schema

  • Use triggers to emit events

  • Send via Python scripts to external systems

Note: The triggers are the same in system events and Response Actions. This is based on customer preferences and tooling. If you are unsure which method is best for you, contact Dropzone Support.


What are some key things to monitor?

1. Investigation Lifecycle

  • Investigation started/stopped

  • Investigation failures (application errors)

  • Inconclusive outcomes (requires human intervention)

These indicate whether Dropzone is successfully processing alerts.

2. API Key & Authentication Events

  • API key creation/revocation

  • Users performing actions outside of their assigned role or taking negative actions

API key issues can silently break integrations if not tracked.

3. System & Operational Events

  • User authentication changes

  • Admin actions

  • License / system updates

Useful for auditability and operational awareness.

4. Integration Events

  • Integration failures can stop alerts from flowing to Dropzone or prevent critical data enrichment

5. Response Action Outcomes

  • Response actions are python scripts run by Dropzone in response to a trigger. If these are failing you could be missing critical visibility into external systems.


What does “good” monitoring look like?

A complete monitoring setup should cover:

  • Ingest: Are alerts entering Dropzone?

  • Process: Are investigations completing successfully?

  • Response Action Output: Are results written back correctly?

  • Integration: Are systems up for alert ingestion and data enrichment?

  • Auth: Are users performing their roles

This ensures full visibility across the pipeline.

Last updated

Was this helpful?