SignalPress records every connection test and delivery attempt in a diagnostic ledger. Use it to confirm credentials, trace failures, and answer support questions without sending another signal.
This article covers connection tests, the delivery log on each integration, and the cross-service Recent Activity view. For durable retries and event identifiers, see Reliable Delivery and Event IDs. For a first-time walkthrough, see Your First Connection Test.
Connection tests
Integrations that support testing expose Send test signal on the integration Settings tab.
Who can run tests
Users need the Test services permission (Tier 2 role matrix) or WordPress Administrator access. See Permissions and Access.
What a test does
- SignalPress sends a small
signalpress_testpayload to the service you are configuring. - The HTTP request is blocking so the result is known before the page reloads.
- A row is written to the delivery ledger and the Connected / Failed badge on Settings updates.
Normal signal delivery is non-blocking where supported — the ledger shows Async for those rows because SignalPress does not wait for a remote HTTP response. Connection tests are the exception.
Test signal naming in logs
The outbound capture uses the event name signalpress_test. The delivery log Event column shows signalpress test (with a space) for connection tests. Filter and search using the log column value.
Test log status
Connection tests use their own status values:
| Status | Meaning |
|---|---|
connected | Last test succeeded |
failed | Last test failed (message on screen and in the log) |
These differ from normal captures, which use dispatched, failed, filtered, or queued.
Settings status badge
After reload, the Settings tab shows Connected or Failed based on the most recent test for that service only. It does not reflect other integrations or ordinary captures.
Each integration Help tab documents provider-specific success criteria under Troubleshooting.
Where to find logs
| View | Location | Scope |
|---|---|---|
| Service Logs tab | Open an integration → Logs | One service |
| Recent Activity | SignalPress → Recent Activity (left menu) | All services |
| Local signals | SignalPress → Local → Logs | Local storage only |
Recent Activity is a top-level menu item, not a tab under Settings. Users need View logs (or administrator access).
Delivery logs are available on all license tiers. Retention and export limits vary — see Free vs SignalPress Pro.
Retention by tier
| Tier | Retention | Display |
|---|---|---|
| 0 (Free) | 24 hours, up to 10 rows per service | Latest entries only |
| 1 (Plus) | 90 days | Full retained history, 20 rows per page |
| 2 (Pro) | Until cleared | Full retained history, 20 rows per page |
Old rows are pruned automatically. On Tier 2, use Clear records to remove history manually.
Log columns
Each delivery row includes:
| Column | Meaning |
|---|---|
| Date / Time | When SignalPress recorded the row |
| Status | Outcome — see [Status values](#status-values) |
| Project | Project label from site or event context |
| Event | Event name (for example checkout_completed or signalpress test) |
| Actor | Who triggered the capture — see [Actor column](#actor-column) |
| Origin | Where the capture was initiated — see [Origin column](#origin-column) (when Capture origin is enabled) |
| Message | Human-readable summary |
| HTTP Status | Numeric code for blocking requests; Async for non-blocking handoff |
| Payload | Expandable redacted preview (when permitted) |
On SignalPress → Recent Activity, rows also include a Service column identifying which integration handled the delivery.
Rows sort newest first by internal log ID. Date sorting uses the same chronological order, not localized display strings.
Actor column
The Actor column shows who triggered the capture at record time:
| Value | Meaning |
|---|---|
| Email address | Logged-in WordPress user (stored as their account email) |
| IP address | Anonymous visitor (best-effort client IP from the request) |
| — | Unknown (no logged-in user and no usable IP) |
In the admin table, email actors link to the WordPress user profile in a new tab. IP actors link to [ipinfo.io](https://ipinfo.io/) in a new tab.
SignalPress stores the actor in the log row itself (actor column on {prefix}signalpress_logs and {prefix}signalpress_local_events). It does not copy display names, usernames, or roles into payload previews. Logged-in captures still include numeric wp_user_id in context for correlation — see Event Context and Options.
Older rows captured before the actor column existed may show an email derived from stored context when the dedicated column is empty.
Origin column
When Capture origin is enabled under SignalPress → Settings → Settings, each row can include an Origin value such as plugin:my-plugin · wp-content/plugins/my-plugin/file.php:47. The column helps you find which plugin or theme file called sp_capture().
- Local logs and delivery logs both show Origin when the setting is on.
- Rows captured while the setting was off have an empty Origin column.
- JavaScript capture shows
browseras the component instead of a PHP file path.
Observability integrations (PostHog, Mixpanel, GA4, Sentry, and similar) receive capture origin in event context. Notification integrations (Slack, Email, Discord, Teams, Pushover) do not — see Capture Origin.
Status values
| Status | Typical cause |
|---|---|
dispatched | Event handed off successfully (or queue worker completed delivery) |
failed | Transport or provider error |
filtered | Blocked by routing, request rules, or a delivery hook |
queued | Stored in the Tier 2 delivery queue pending worker run |
connected | Connection test succeeded |
failed | Delivery or connection test error |
A queued event usually produces two ledger rows over time: queued immediately, then dispatched or failed when the worker finishes.
HTTP Status column
- Connection tests — numeric response (for example
200,202,401). - Normal remote delivery — Async because SignalPress fires the request without waiting.
- Local — stored immediately; no remote HTTP status.
Payload previews
Expand Payload to inspect a redacted copy of what was sent. SignalPress redacts secret-like keys, limits nesting depth, truncates long strings, and caps collection sizes. Full outbound payloads are not stored.
Users without View payloads (Tier 2 roles) may see rows without expandable previews. Administrators always have full access.
Working with log tables
On Plus and Pro:
- Sort and filter every column across the full retained dataset
- Change page size
- Refresh logs without leaving the page
- Download CSV for the current filtered view
On Free, the table shows the latest retained entries without full-history pagination.
Enable Auto refresh to poll every 10 seconds — useful after connection tests or queue processing.
Clearing history
| Action | Permission | Effect |
|---|---|---|
| Clear one service | Clear logs | Removes that service’s delivery rows |
| Clear all services | Clear logs on Recent Activity | Empties the full ledger |
| Clear Local signals | Administrator / configured roles | Separate Local signal store |
Deletion requires confirmation and uses WordPress nonces.
Local vs remote logging
Local uses a separate event store (signalpress_local_events) with the same table UX (sort, filter, CSV on Tier 1+). Local captures are never queued.
Local log columns
Each Local row includes:
| Column | Meaning |
|---|---|
| Date / Time | When the signal was stored |
| Event | Event name passed to sp_capture() |
| Source | source value from the capture options |
| Actor | Who triggered the capture — see [Actor column](#actor-column) |
| Origin | Where the capture was initiated — see [Origin column](#origin-column) (when Capture origin is enabled) |
| Level | Event severity when provided in the payload |
| Project | Project label from site or event context |
| Environment | Environment label from site or event context |
| Payload | Expandable stored payload preview (when permitted) |
| Context | Expandable generated SignalPress context preview (when permitted) |
Remote services write to {prefix}signalpress_logs.
Relating logs to captures
Every PHP capture adds event_id, request_id, and correlation_id to context automatically. They appear in payload previews and help match retries to the original capture. Details: Reliable Delivery and Event IDs and Event Context and Options.
Rejected events (validation failures) are not written to the ledger.
Common support scenarios
“Test says Connected but real events fail” — Compare a test row (connected, event signalpress test) with a failed capture row. Check routing rules, request rules, and provider credentials.
“I see Async but nothing in PostHog” — Async only means SignalPress handed off locally. Confirm the provider received the event on their side; use event_id from the payload preview to search downstream.
“Status is filtered” — The event never left WordPress. Review routing on the integration Routing tab and Tier 2 request rules.
“Logs disappeared” — Free tier retention is 24 hours / 10 rows per service. Upgrade or export CSV on Plus before rows age out.
What to read next
- Your First Connection Test — step-by-step first test
- Reliable Delivery and Event IDs — queue, cron, and identifiers
- Permissions and Access — who can view, export, and clear logs
- Advanced Event Routing — why rows show
filtered - Plugin Status Endpoint — automated health checks (Tier 2)