# Monitor active data-changing requests

Coordinator DB applies `UPDATE` and `DELETE` immediately within the current transaction. There is no asynchronous mutation queue to poll after those statements have completed. Observe active requests and then verify their terminal outcome.

```sql
SELECT query_id, user, query_kind, elapsed, written_rows
FROM system.processes
WHERE query_kind IN ('INSERT', 'UPDATE', 'DELETE')
ORDER BY elapsed DESC;
```

The query classification describes the current statement. A request can contain several statements, so keep its query ID when correlating it with history. Deleted rows are not counted as newly written rows; a zero `written_rows` value does not prove that a DELETE removed nothing.

After completion, inspect the exception fields and confirm the intended data state with a SELECT using the same predicate. A statement inside an explicit transaction is not committed merely because the statement itself finished. HTTP transactions must complete inside one request; an open transaction is rolled back before the response is sent.

Use small, reviewable predicates and transaction controls for maintenance work. Do not wait for an undocumented background table to report completion.

See [`UPDATE`](https://coordinatordb.com/docs/reference/statements/update), [`DELETE`](https://coordinatordb.com/docs/reference/statements/delete), [transactions](https://coordinatordb.com/docs/concepts/features/operations/insert/transactions) and [active requests](https://coordinatordb.com/docs/reference/system-tables/processes).