Reliable Delivery and Event IDs

SignalPress assigns stable identifiers to every capture and, on Tier 2 (Pro), can queue remote deliveries for retry when transport fails. Use this guide for support tickets, cross-system tracing, and production cron setup.

For log columns and connection tests, see Connection Tests and Delivery Log. For context field reference, see Event Context and Options.

Event identifiers

Every PHP capture through sp_capture() / signalpress_capture() receives three IDs in context unless you override them in the options array:

ID	Scope	Default	Purpose
event_id	One capture call	New UUID	Unique idempotency key for that event
request_id	One WordPress HTTP request	Shared UUID via signalpress_request_id()	Tie multiple captures from the same page load
correlation_id	Your workflow	Same as event_id	Link related work across requests or retries

Override in code

PHP

sp_capture(
	'order_exported',
	[ 'order_id' => 90210 ],
	[
		'event_id'        => 'export-90210-v1',
		'correlation_id'  => 'order-90210-lifecycle',
		'request_id'      => signalpress_request_id(), // optional; usually omit
	]
);

Providers receive these fields in context. They appear in delivery log payload previews.

Practical tracing

• Search downstream systems by event_id when debugging a single capture.
• Group admin actions in one request with request_id (for example several sp_capture() calls during checkout).
• Follow a business process across requests with correlation_id (for example payment webhook → fulfillment capture).

Queued retries preserve the original context JSON, so event_id and correlation_id stay stable across attempts.

Durable delivery queue (Tier 2)

When enabled, remote service deliveries are stored before HTTP handoff and processed by a background worker. Local events remain immediate and are never queued.

Open SignalPress → Settings → Delivery Queue. Requires Manage delivery queue permission (or administrator).

Enable the queue

1. Confirm Tier 2 (Pro) license is active — Free vs SignalPress Pro.
2. Open Settings → Delivery Queue.
3. Check Queue remote service deliveries and save.

The dashboard shows Pending, Retrying, Failed, and Oldest pending counts.

Default settings

Setting	Default	Range
Delivery frequency	15 seconds	5 s, 15 s, 1 min, 5 min
Maximum attempts	5	2-10
Initial retry delay	60 seconds	30-3600 seconds

Retries use exponential backoff from the initial delay (capped at one day). After the last failed attempt, the queue row moves to Failed and a failed ledger row is written.

What the worker does

Each run processes up to 20 pending rows:

1. Reconstruct the event from stored properties and context.
2. Call the provider’s capture method (blocking).
3. On success — delete the queue row and write a dispatched ledger row.
4. On transport error — schedule retry or mark permanently failed.

Use Process pending deliveries now to run the worker immediately without waiting for cron.

Ledger behavior with the queue

Without the queue, successful handoff logs dispatched with message “Event dispatched without waiting for the remote response” and HTTP Status Async.

With the queue enabled:

1. Immediately — queued row (“Event stored in the durable delivery queue”).
2. After worker success — separate dispatched row (“Queued event handed to the remote service”).
3. After permanent failure — failed row with the last error message.

Filter by correlation_id or event_id in payload previews to connect both rows.

WP-Cron behavior

SignalPress registers two hooks:

Hook	Schedule	Role
signalpress_process_delivery_queue	Every minute	Safety worker (always scheduled)
signalpress_kick_delivery_queue	Single event after each enqueue	Faster processing at chosen frequency

Sub-minute Delivery frequency values are targets. WordPress cron only runs when something hits the site (unless real server cron is configured). The one-minute safety worker still runs.

Server cron setup

For predictable queue processing — especially low-traffic sites — install a real cron job that triggers WordPress cron once per minute.

Copy the command from Settings

Settings → Delivery Queue shows a ready-made command, for example:

Shell

* * * * * curl --fail --silent --show-error 'https://yoursite.example/wp-cron.php?doing_wp_cron' >/dev/null 2>&1

Replace the URL with your site’s wp-cron.php endpoint. Confirm curl is available on the server and test with your host before installing.

Optional: disable WP-Cron on web requests

After server cron is verified, add to wp-config.php:

PHP

define( 'DISABLE_WP_CRON', true );

WordPress will no longer spawn cron on page views; the server job becomes the sole trigger.

Verify processing

On the Delivery Queue tab, check Last worker run and Next safety run. Pending counts should drop after the worker runs. Confirm queued → dispatched rows in Recent Activity.

When the queue does not apply

The queue filter returns early (immediate delivery) when:

• Queue is disabled in settings
• License is below Tier 2
• Target service is local
• Another filter on signalpress/deliver_service_event already handled delivery

Routing blocks and validation failures never enter the queue.

Monitoring at scale

For automated uptime checks without loading wp-admin, use the Plugin Status Endpoint (Tier 2). It reports license health and whether each active service is configured.

What to read next

• Connection Tests and Delivery Log — statuses, retention, CSV export
• Event Context and Options — full context field list
• Capturing Events with sp_capture() — capture API and return values
• Permissions and Access — Manage delivery queue role grant
• Plugin Status Endpoint — REST health monitoring