The BTP Application Events Monitor tracks and alerts on audit events within your SAP BTP Cloud Foundry environment. It allows for granular tracking of application lifecycle changes, security events, and operational actions by communicating with the Cloud Foundry V3 Audit Events API.

• Network connectivity from the collector to your BTP API endpoints (e.g., api.cf.eu10.hana.ondemand.com).
• BTP Credentials: A User Profile with at least Space Auditor permissions for the targeted spaces/organizations.
• Endpoints accessed: /v3/audit_events: To retrieve the stream of events for specific applications, spaces or organizations. /v3/apps: To resolve application, space and organization names into GUIDs.
• Authentication: OAuth2 Password Grant (handled automatically using the configured User Profile).

The monitor captures detailed information for every discovered event:

1. Event Type: Lifecycle events (audit.app.update, audit.app.restage), crashes (audit.app.process.crash), or any other Cloud Foundry audit event.
2. Actor Details: Identifies who initiated the event. The actor is a user for manual actions, and a process or the application itself for platform events such as crashes.
3. Target Info: Maps events to the affected resource, and to its Space and Subdomain.
4. Contextual Data: Captures reasons, exit descriptions, and instance IDs where available.

Audit events do not only target applications: service keys, routes, bindings and spaces produce events too. Those are reported with their TARGET_TYPE and TARGET_NAME, and with an empty APP_NAME.

1. Event Type Filtering: Monitor specific events (e.g., only audit.app.process.crash) or use * for everything.
2. Scope Control: Filter by Application Name, Space, or Subdomain. Values are matched exactly (case-insensitive), or * for all. Partial wildcards such as myapp* are not supported.
3. Temporal Precision: Each cycle collects the events created since the previous run, with a deliberate overlap, and removes the duplicates that overlap produces.

1. Event-Based Alarming: Trigger an alarm immediately when an event matching your criteria is detected.
2. Unique Identification: Each alarm is tied to the BTP Event GUID, ensuring multiple events of the same type in one cycle are all reported.
3. Configurable Severity: Assign a severity per configuration row.
4. Event alarms are never cleared automatically: they report something that happened, not a state that persists.

The monitor emits one counter per event type and application for each cycle:

• Metric: promonitor.btp.cloud_foundry.audit_events.count
• Tags: event_type, app_name, space_name, subdomain_name
• Value: the number of matching events collected in that cycle

Only the combinations that actually occurred are sent, a cycle without events sends no metric. This makes it possible to alert on a rate (for example more than three crashes in an hour), which per-event alarms cannot express. It also catches crashes that the BTP Application Stats monitor cannot see: an application that crashes and restarts between two polls never shows a crashed instance, but always produces an audit event.

1. Metadata Sync: At every run the monitor loads the applications, spaces and organizations from /v3/apps, so that human-readable names can be used in the configuration instead of GUIDs. This list is not kept between runs, it is always current.
2. Request Generation: For each active row a filtered API request is built using the created_ats[gt] parameter. Rows filtering on an application use target_guids, rows filtering only on a Space or a Subdomain use space_guids and organization_guids so that the API does the filtering.
3. Pagination: Events are read 1000 per page, up to 10 pages per row and per cycle. If that limit is ever reached a warning is written in the collector log naming the request.
4. Metadata Storage: Discovered events are stored as metadata (visible in the Event Log/Reports). Metadata, Metrics and Alarm are independent: disabling one does not disable the others.

Each cycle collects the events created since the previous successful run, minus a five minute overlap. The overlap is deliberate: the Cloud Foundry documentation states that audit event timestamps come from different Cloud Controller instances and are not guaranteed to be ordered, so a strict window would silently drop late events.

If the monitor has not run for a long time, it looks back at most 60 minutes.

If any request of a cycle fails, the window is not advanced. The events are collected again on the next cycle instead of being lost, and the collector log states that the collection was incomplete.

The overlap above, and several other situations, cause the same event to be read more than once. The monitor reports each event exactly once:

1. Crash events: Cloud Foundry emits both audit.app.process.crash and the legacy app.crash for a single crash. Only the audit.* event is reported, unless the row explicitly asks for app.crash in its Event Types.
2. Overlapping rows: an event matched by several rows is reported once, under the first matching row. Rows resolving to exactly the same query are collected only once.
3. Between cycles: the GUIDs of the reported events are remembered and re-reported events are discarded.

A Test run does not use this memory: it always shows what the configuration matches, even if the scheduled runs already reported those events. This also means a Test run never marks events as reported.

1. Create a Web Service Connector:
2. URL: Your BTP API endpoint (e.g., https://api.cf.eu10.hana.ondemand.com).
3. Auth Type: Associate with a User Profile containing valid BTP credentials.

1. Open the monitor configuration.
2. Click the “Load BTP Apps” button.
3. The table will populate with known applications.
4. Specify the Event Types you wish to monitor for those apps (e.g., audit.app.process.crash).

To monitor all events across a whole space or subdomain:

1. App Name: Set to *.
2. Space / Subdomain: Enter a specific name to filter, or * for the entire subaccount.
3. Event Types: Set to * to see every audit event.

A row filtering on a Space or a Subdomain without an application name reports every audit event of that scope, including the events that do not target an application. Narrow the Event Types on such a row if you enable its Alarm, otherwise every platform event raises one.

App Name, Space, Subdomain and Event Types are mandatory. A row left empty is a misconfiguration and is skipped, with a warning in the collector log: an empty filter is never treated as *.

The most common setup. One row per application, obtained with the “Load BTP Apps” button, narrowed to crash events.

What you get, for each crash:

• One alarm: BTP Event: audit.app.process.crash [App: payment-service][Space: production][Subdomain: acme-prod][Actor: web][Date: 2026-08-14T09:51:02Z]
• One metadata row, with REASON=CRASHED and EXIT_DESCRIPTION giving the exit status (for example Exited with status 137 (out of memory))
• One metric point: audit_events.count = 1, tagged event_type=audit.app.process.crash, app_name=payment-service

Note that Cloud Foundry emits a second, legacy app.crash event for the same crash. It is dropped automatically, so a crash produces one alarm and a count of 1, not two.

The Actor of a crash is web, the application process. Crashes are not user actions, so no user name is reported.

Useful for compliance or for investigating afterwards, when you want the record but not the noise.

What you get:

• Every audit event of that space, stored as metadata: application lifecycle, but also service keys, routes, bindings and space changes
• For an event that does not target an application, APP_NAME is empty and the resource is described by TARGET_TYPE and TARGET_NAME, for example TARGET_TYPE=service_key, TARGET_NAME=db-credentials

Metrics are disabled here on purpose: with Event Types set to * a busy space produces a separate counter for each of the many Cloud Foundry event types.

Alarm is disabled for the same reason. Every deployment, restart and binding change of the space would raise one.

No scope filter at all, narrowed by event type instead.

What you get:

• Those four event types wherever they happen in the subaccount, whatever the space
• Alarms naming the affected resource rather than an application, for example BTP Event: audit.service_key.create [Target: service_key db-credentials][Space: production][Subdomain: acme-prod][Actor: alice@example.com][Date: …]
• Metric points with an empty app_name tag, since those events do not target an application

This is the row type where the Actor is most useful: these are user actions, so ACTOR_NAME is the user who performed them.

The monitor stores data under the category: BTP_APP_EVENTS

Every field is always present, a field that does not apply to an event is empty.