Logs

What logs show

Open Dashboard → Integrations → Logs to review recorded workspace activity: what happened, which record was affected, when it happened, and who performed the action. Logs are separate from click analytics and from your receiver's server logs. They do not require a configured webhook.

Plan history windows

Free shows 7 days, Pro 30 days, Business 90 days, Enterprise 180 days, and Elite 365 days. These are viewable activity-history windows, separate from analytics retention. Server-side filtering applies the window to every page and filter. Downgrades hide older entries without deleting them; upgrades reveal additional history only if it is still retained. Recording supported activity continues regardless of the viewing allowance. Logs do not consume tracked-click/event quota.

Access and availability

The feature must be enabled in your deployment. You need an active account with the Owner or Workspace Admin role. There must be at least one active collection; blocked or removed memberships do not count. Selecting a collection does not narrow the log to that collection: this is workspace-wide information. Collection members and API keys cannot use this view. There is no public log-reading API or plan upgrade requirement.

Browse and filter

  1. Select the workspace you want to inspect, then open Integrations → Logs.
  2. Filter by resource, such as links or webhooks, and optionally by its associated action. Selecting a different resource resets the action filter.
  3. Read the newest results first. Use the older-results control when another page is available; pages contain at most 50 entries.
  4. Clear filters if no matching activity appears. No results can also mean no activity has been recorded yet.

Action names use dots, for example link.created, link.destination.updated, or webhook.disabled. They describe recorded facts, not commands to execute.

Fields and privacy

Each log fact stores its own ID, workspace ID, affected record ID, action, actor ID, operation ID, and occurrence time. The actor identifies a human profile or API key; a null actor means a system action. An operation ID groups related changes, including bulk actions. Treat identifiers as sensitive business data.

Logs do not store full records, before/after values, passwords, signing secrets, or arbitrary submitted form contents. They cannot reconstruct or restore a deleted record. Global account/profile activity is not exposed in this workspace view.

Where present, entries show the associated webhook name, delivery state, and result category:

  • pending: no attempt has started. This is not a scheduled retry or a guarantee of future delivery.
  • Unconfirmed (unknown): an attempt was claimed, but no terminal result is recorded. The UI never treats it as success or failure, and Hoko cannot prove whether the receiver received it.
  • succeeded: the sender recorded a successful response, not proof that the receiver completed its business work.
  • failed: the sender recorded a failure. Inspect the category and fix the receiver.

From a log row's More options menu, an Owner or Workspace Admin on an active Business or higher plan can resend a pending, Unconfirmed, or failed delivery. Hoko waits five minutes before allowing an Unconfirmed delivery to be resent. A pending delivery uses its existing first attempt; a failed or old Unconfirmed delivery adds a new attempt. Every send keeps the original event ID and uses a new signature timestamp. Your receiver must deduplicate the event ID because the earlier request may have reached it.

If an endpoint is disabled, use Verify and enable on the Webhooks page to send a fresh challenge to its saved receiver with its saved signing secret. A successful challenge keeps the endpoint ID and delivery history, then changes the endpoint to active. Delivery stays off until the challenge succeeds. Deleting an endpoint clears its receiver and signing secret, so it cannot be re-enabled.

No delivery shown does not mean the action failed. There may have been no eligible subscription or publication may have been disabled. A log can exist without any webhook delivery. Read Webhooks for testing and troubleshooting.

History limitations

Logs show facts actually recorded by enabled application flows. They are not a retroactive history of all existing records, a database backup, or a guarantee that every external or direct database change is captured. A failed transaction does not leave a successful-change log.

With data export access (Business or above), select visible rows and choose Download selected. The button shows the selection count. The JSON download contains log IDs, timestamps, actions, record IDs, actor IDs, and operation IDs from the current page only, not hidden history or delivery details. Treat downloaded identifiers as sensitive. Logs do not provide edit or delete controls. Use a delivery row's More options menu to resend an eligible webhook delivery. Delivery history is retained for the workspace lifetime, including after endpoint deletion. Deleted endpoints cannot deliver or be resent; workspace deletion can remove associated logs.

If access is denied, check that you are the workspace Owner or Workspace Admin and that the deployment enables logs. Buying a different plan does not bypass those checks. See the technical log reference.