# Events

How one part of an app tells the others that something happened: declaring an event, emitting it and subscribing to it.

| Page | What it covers |
|---|---|
| [Declaring an event](/docs/declaring-an-event.md) | An event records that something happened, so that other code can react to it later without the action that caused it waiting. |
| [Emitting an event](/docs/emitting-an-event.md) | An action announces an event with `emit`, a statement written like `reject` (Raising a failure). |
| [Subscribers](/docs/subscribers.md) | A subscriber reacts to an event: each time the event is committed, it runs an action. |
| [Background work and tenants](/docs/background-work-and-tenants.md) | In an app with a `tenant:`, each kind of background work reaches a stated set of tenants. |
| [Reacting in another domain](/docs/reacting-in-another-domain.md) | One domain changes another in one of two ways (Ownership and calls replace modules): it calls one of the other domain's `public` actions, or it emits an event the other domain subscribes to. |
| [Long-running coordination](/docs/long-running-coordination.md) | A process that waits for several things over time, such as an order waiting for both payment and stock, needs no workflow language. |
| [Where events travel](/docs/where-events-travel.md) | Events stay inside the Jadpo runtime. |
| [Events from outside](/docs/events-from-outside.md) | Besides the events your actions emit, four sources outside the app produce events: webhooks, a package's own events, polls and queues. |