Use Settings to configure Local, Routing to select events, Logs to search stored Local records, and Help for this guide. Routing requires Tier 1; Tier 2 adds request rules. Log visibility, payload previews, and deletion can be delegated separately with Tier 2 role permissions.
Send signals to Local to store events in WordPress without a third-party destination.
Local is the default free SignalPress service. It stores selected events in a dedicated WordPress database table without sending them to a third party.
Hub service ID: local. Index: Integrations Overview. Target from PHP: Service Targeting.
The Send test signal button performs a real end-to-end database insert. A successful test creates a signalpress_test record in the Logs tab and reports its record ID in the connection panel.
Setup
- Activate Local from SignalPress → Integrations. New installations activate it by default.
- Open Local → Settings and enable the service.
- Choose the payload/context storage options under Settings.
- Use Routing to decide which server-side events Local should store.
- Under Logs, choose the maximum number of records to retain, then browse, sort, filter, and inspect captured records.
When the record limit is reached, Local removes the oldest entries. Local records are separate from the delivery ledger used by remote services.
Send a signal to Local
PHP
sp_capture( 'order_reviewed', [ 'order_id' => 123, 'message' => 'The order entered manual review.', 'level' => 'warning', ], [ 'source' => 'fraud-check', 'services' => [ 'local' ] ] );
Expand Payload / Context in the Local table to inspect the caller payload and generated SignalPress context independently.
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 below |
| Origin | Where the capture was initiated — 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) |
Origin column
When Capture origin is enabled under SignalPress → Settings, Local rows include an Origin column with the plugin, theme, or file that initiated the capture. Filter and sort on Origin like any other column. See Capture Origin.
Actor column
Each Local row includes an Actor column with the email address of the logged-in WordPress user or the anonymous visitor's IP. Click an email to open that user's WordPress profile; click an IP to open its ipinfo.io page. The value is stored in the actor column on {prefix}signalpress_local_events.
For logged-in requests, generated context also includes the numeric wp_user_id. SignalPress does not copy display names, usernames, roles, or other profile fields into payload or context automatically.
Use Tabulator's Page Size selector below the table to show 10, 25, 50, or 100 records per page. The table initially shows 25 records per page and refreshes automatically every 10 seconds while its browser tab is visible. Its Auto refresh checkbox sits beside Clear records, and the browser remembers that Local-specific preference.
Send signals locally during development
PHP
if ( 'production' !== wp_get_environment_type() ) {
sp_capture(
'integration_debug',
[ 'response_code' => 202, 'attempt' => 2 ],
[ 'source' => 'custom-integration', 'services' => [ 'local' ] ]
);
}
Avoid storing credentials, authentication tokens, personal data, or other secrets. SignalPress applies preview safeguards, but Local is not intended to be a secure secrets store.
Redacted keys
Additional redacted keys is a Local privacy and storage control, not a routing filter. Add project-specific payload or context keys such as customer_email, phone, or internal_note to prevent their values from being stored in Local records. SignalPress already redacts keys resembling passwords, tokens, secrets, API keys, authorization values, and cookies.
Redaction matches field names recursively. It changes only the payload and context saved by Local; it does not decide whether an event is captured and does not alter the data delivered to another integration.
Routing example
To keep only scheduled-task failures, set Include Event Patterns to *_failed, Include Sources to cron:*, and Routing Minimum Level to Warning and above. Local applies those rules before inserting a record.
Include and exclude event patterns match the first argument passed to sp_capture(). For example, exercise_* matches sp_capture( 'exercise_milestone_reached', ... ). Source patterns match the options array's source value, while minimum level reads level from the event data array.
What to read next
- Integrations Overview — browse and activate services
- Your First Connection Test — send a test signal and read the log
- Advanced Event Routing — per-service event filters
- Connection Tests and Delivery Log — interpret delivery results
- Service Targeting — limit destinations from PHP