Much of what your project does happens after a request: a flow started by an event, an email, a webhook delivery, a scheduled sweep. The Background work and Events and messages groups of Activity show all of it. Every page has the same time buttons as the rest of Activity.

​
Flow runs

Activity → Flow runs charts runs over time and lists Recent failures, then every run, newest first. Filter by flow and by status. Open a run to see its trace: every block in the order it ran, with its input, its output, the exit it took and how long it took, plus the run’s input, its result and its logs. A run started by a request or a job links to them, so you can move between the request, the job and the run. Traces are kept only for flows with Record runs on (see flow settings). How long they’re kept depends on your plan.

​
Reading a failed run

  1. Find the last block in the trace. That’s where it stopped.
  2. Read its error. Common ones: a value that was empty because a path was wrong, a record that wasn’t found, an HTTP call that failed, a run that hit its timeout.
  3. Compare the block’s input with what you expected. Look at the output of the block before it.
  4. Fix the flow, then retry the job or run it again.

​
Jobs

Activity → Jobs shows queue depth and counts per queue, jobs over time, and every job with its status (queued, active, retrying, completed, failed). Gave up after retrying lists permanent failures. How failed work is retried explains each kind’s retry policy. Retry one job, or replay many after an outage. See Background jobs.

​
Events

Activity → Events lists recent events, newest first, with a filter by name (orders.created). Open one to see its full envelope and every consumer it reached: each flow, realtime channel and webhook, and whether handing it over worked. Send test event emits an event of your own with a name and payload: the quickest way to test a subscription or a flow trigger.

​
Event map

Activity → Event map draws which events exist, what emits them (tables, sign-in, flows, schedules, hooks), and what consumes each (subscriptions, flow triggers, webhooks). Use it to:
  • see everything that happens when a table changes,
  • spot events that nothing listens to,
  • find which flow is reacting to something unexpectedly.

​
Webhooks

Activity → Webhooks shows deliveries over time, by endpoint (with failures), the busiest events and where they come from, and recent failures. For every delivery and redelivery, see Webhook deliveries.

​
Mail

Activity → Mail shows messages sent and failed by template. For individual messages, see Mail activity.

​
Realtime

Activity → Realtime shows the busiest channels, the latest deliveries, and policy errors: subscriptions or publishes that a channel rule refused. A burst of policy errors usually means an app is subscribing to channels its users aren’t allowed on. See Monitoring realtime.

​
Follow one action everywhere

An action in your app can set off a chain: a request writes a record, the table emits an event, a subscription starts a flow, the flow sends an email and a webhook. Every link carries the same request id: Start from whichever you have (a request id from your app’s error, an event, a failed job) and follow the links to the rest. See Requests and traces.

​
From code