anchor.diff:  
   - audit.app.crash
   - blob.remove\_orphan
  +
  +## When are events created?
  +
  +Most events are created when a user acts upon a resource.
  +For example, a user issuing a `cf stop APP_NAME` command will cause an `audit.app.stop` event to be created and associated with that user.
  +
  +Service Events (`audit.service*`) are created after the service broker has approved an interaction.
  +
  +Crash events (`audit.app.crash`) are created when Diego marks an application instance as crashed.
  +
  +Blob events (`blob.remove_orphan`) are created by a daily clean up job and do not represent user action.
  +
  +## Considerations
  +Audit events can be created at any point during the execution of the action they describe. This means the action associated with the event is **not** guaranteed
  +to have succeeded.
  +
  +The audit events table can grow to be very large. So, for performance considerations, certain database migrations may result in the truncation of this table.
  +In other words, this means that a deployment with such a migration will result in a loss of events.
  +These migrations are exceedingly rare and any release of capi-release that includes one will note this behavior prominently in its [release notes](https://github.com/cloudfoundry/capi-release/releases).
  +
  +The order of audit events returned from the API is **not** guaranteed to match the sequence of events that occurred in the system.
  +
  +The timestamps on events should not be relied on to sequence events - they may come from different Cloud Controller instances whose time could be slightly mismatched.
  +
  +Audit events expire after 31 days by default. This is configurable using the capi-release manifest property `cc.audit_events.cutoff_age_in_days`.
  
positive.code: ### External Auditing Warehouse
  
  For auditing and compliance reasons, some operators may wish to keep a record of all audit events that have occured. Because audit events expire
  and may be purged during a deploy, these operators are must maintain an external data warehouse. This way they can store and access events across expiration events
  and conform to their own compliance requirements.
  
  ## Types of Audit Events
  
negative.code: 
  Another tool to help administrators monitor user actions on Cloud Foundry is [Security Event Logging](../../loggregator/cc-uaa-logging.html).
  Unlike Security Event Logs, audit events do **not** cover all API endpoints, but provide more details about a user's actions.
  
  ### Viewing Events
  
  