Notifications
Pharos delivers two different things to the same set of destinations. An advisory is what a watchlist raises, and each watchlist names its own destinations when it is created. A platform event is something the service itself noticed, such as the monthly limit being reached, and where each kind of event goes is decided once for the whole workspace, on the Events tab of Settings, Notifications. The destinations both lanes use are on the Channels tab, and everything ever sent to the in-app inbox is on the History tab.
Destinations
The in-app inbox needs no setup and cannot be removed. The four external destinations are configured once, one of each kind per workspace. Adding a kind already configured replaces its destination.
| Destination | What to provide |
|---|---|
One or more addresses. Mail comes from noreply@pharos.notifications.wazuh.com, and empty digests are not sent | |
| Webhook | An https:// endpoint, plus an optional signing key. Every payload is HMAC-signed in an x-pharos-signature header. When no key is supplied, the service signs with its shared key |
| Slack | An incoming webhook URL for the channel that should receive messages |
| Jira | The site URL, the project key, an optional issue type, the account email and an API token. A matching event becomes an issue in that project |
A Slack incoming webhook URL is a bearer token, and a Jira API token is one by definition, so both are stored out of sight. What the console shows back is a masked hint, never the value: for email, the first three addresses. For a URL, the scheme and host with the path dropped. There is no screen that displays a stored secret again. Changing a destination replaces the stored value and marks it unproven until it is tested.
Until the workspace has been switched on, as described in Signals, the in-app inbox is the only destination that delivers. The others can be saved but nothing is sent to them, and the page says so.
The Test button
Every external destination has a Test button, and a test is a real send to the real destination, not a check of the form:
- Slack receives a visible message saying it is a test and no action is needed.
- Webhook receives one signed payload whose body carries
"kind": "test", so the receiver can tell it apart from a live event. - Jira is signed into and the project is looked up. No issue is created, on purpose, so nothing is left in the project.
- Email receives one message with the subject "Pharos test message".
A destination that has never passed a test reads "Configured, never proven". One that has passed reads "Verified", with the date. A test that fails shows what the destination answered, so a wrong URL or an expired token is diagnosed from the page rather than from a missing message a week later.
Routing platform events
The Events tab is a table of event types against destinations. Each cell is a tick: tick it and that event goes to that destination, untick it and nothing is sent there. The in-app column is always present. An external column appears once its destination is configured. Severity is a colour in the bell and a chip in the history, not a routing input, so a critical event goes exactly where its row says.
The events are grouped in four families: Signals, Billing, Fleet and Corpus. The two worth routing on day one are in Billing and Fleet:
| Event | What it means |
|---|---|
| Half the monthly limit, 80% of the monthly limit | The usage notices described in Signals, sent once each per billing month. The 80% notice carries the projection for the month |
| The monthly limit is reached | The fleet's managers have stopped reporting alerts and vulnerabilities. Investigate still works, and reporting resumes within minutes of the limit being raised |
| A manager was enrolled | A new sensor joined the fleet. Worth routing if it matters who adds sensors |
The list on the Events tab is the authoritative catalogue, served by the service rather than hard-coded in the console. Until an admin saves a routing table, a small default set is ticked for the in-app inbox: the 80% and 100% limit notices, a manager going quiet, and a vulnerable package in the CISA KEV catalog.
A watchlist keeps its own destinations. Nothing on the Events tab changes where an advisory goes. That is chosen per watchlist, and is described in Watchlists and advisories.
The bell and the history
The bell at the top of every page shows the newest ten notifications and a badge with the unread total. Opening it marks everything read. Read rows stay in the list, dimmed. The History tab is the whole record: every platform event this workspace has been sent, newest first, with its severity, the event, when it was received and the page it opens. It has no filter or search yet.
Who can change this
Everyone in the workspace can read the Channels, Events and History tabs. Adding, changing, testing or removing a destination, and saving the routing table, are an admin's, and the service enforces that rather than the console merely hiding the buttons. See Team and managers.