Signals
Logs, traces and metrics, and the rule that makes something a signal.
Signals
A signal is an observation upzero received or produced by probing something, never a statement it authored about itself. Three exist:
| Signal | What it is |
|---|---|
| Logs | Discrete, timestamped events your app emits |
| Traces | Spans showing how one request moved through your services |
| Metrics | Numeric measurements over time, including the results of uptime probes |
The rule that makes something a signal
A signal is never edited, never assigned to a person, and never has a status. It's scoped to your organization and to a time range, and it ages out once it passes your retention window. If something needs an owner or a status, it has already left this category, whatever it started as.
That rule is why an uptime check result counts as a metric rather than a category of its own: it's a number, over time, that nobody edits after the fact, the same shape as any other metric. Browser and multi-step synthetic checks are the one exception; a multi-step probe genuinely is a trace, so it emits spans instead.
Where signals go
Everything else in upzero is built on top of signals without editing them:
- Correlation computes patterns from signals, such as which errors are really the same error and which services call which, and can always be recomputed from the signals underneath it.
- An issue is opened when a pattern in your signals crosses a threshold worth a person's attention.
- A service is discovered from the
service.nameyour signals carry.
To send your own: Instrument your app. To look at what arrived: Explore.