Monitor the event bus
What this achieves
Section titled “What this achieves”Every significant action in Humavera raises an event, and things like webhooks, workflow triggers, and notifications subscribe to those events. This page shows the events themselves, so you can tell whether something failed to happen because the event was never raised or because a subscriber did not process it.
Required role: Administrator.
- Go to Integrations → Event Bus.
- Filter by Event Type, Status, Entity Type, or a date range.
- Open an event to see which subscribers processed it.
- Read the Error on a failed event.
- Read the Payload — use Show full payload for the whole of it.
- Select Retry Failed to retry failed events.
What the list shows
Section titled “What the list shows”| Option | Description |
|---|---|
| Event Type | Which event was raised, such as employee.created. |
| Module | Which part of the product raised it. |
| Entity | What kind of record it was about. |
| Status | Whether it was processed. |
| Subscribers | How many subscribers handled it. |
| Time | When it was raised. |
Subscriber types
Section titled “Subscriber types”| Option | Description |
|---|---|
| Webhook | A delivery to an external URL you configured. |
| Workflow Trigger | An approval workflow started by this event. |
| Notification | A notification sent to somebody in Humavera. |
| Skill Recalc | A recalculation of skill data. |
One event commonly has several subscribers, and they succeed and fail independently. Opening the event tells you which ones ran, which is the difference between “the event never happened” and “the event happened and one consumer choked on it”.
Example: an employee.terminated event at HC Corp that raised correctly and notified the right people, but whose webhook subscriber failed, is a receiving-system problem. The same event missing from this list entirely is a different problem, upstream of every integration.
Use it to answer “why did nothing happen”
Section titled “Use it to answer “why did nothing happen””This page is the layer beneath webhooks and workflows, and it is where an integration mystery usually resolves. Work in this order.
- Is the event in this list at all? If not, the action that should have raised it did not complete.
- Did it have subscribers? An event with none has nowhere to go — nothing is configured to listen for it.
- Did the subscribers succeed? A failed subscriber names its error on the event.
Reading the payload
Section titled “Reading the payload”The event carries the data it was raised with. Show full payload expands it and Copy takes it, which is what to send to whoever maintains the receiving system when a delivery is being rejected.
Treat the payload as data about real people. It contains what the event was about, and copying it moves that content somewhere Humavera’s access controls do not reach.
Retrying
Section titled “Retrying”Retry Failed retries every failed event in your organization whose retry count is below the limit. The confirmation states that already-completed events are not affected.
Fix the receiving end first. Retrying against a system that is still down consumes the remaining retry attempts and leaves you with events that have exhausted their limit.
The event’s Retry Count tells you how much room is left. An event at the limit will not be picked up by a retry, and getting it through means replaying the individual webhook delivery instead.
What happens next
Section titled “What happens next”Retried events are reprocessed by their subscribers. Where the failing subscriber is a webhook, the webhook’s own delivery log carries more detail — the request that was sent and the response that came back — and offers a replay for a single delivery rather than a bulk retry.
Related
Section titled “Related”© 2025-2026 Humavera Documentation - BPilot Ltd. All Rights Reserved