A service-focused stream
Send logs with a service name and create a monitor for that service. Separate application and environment names help keep counts meaningful.
Your logs have a story.
Notice the important part.
Turn application log patterns into monitoring signals. Watch error counts, specific messages or a service that has gone quiet, alongside the availability checks for the same stack.
Part of your Uptiva workspace · One workspace. Every signal.
12:04:08INFO checkout.request.completed12:04:09INFO payment.accepted12:04:10INFO order.confirmed12:04:12INFO checkout.request.completed
No matching errors in the current window
- Service
- checkout
- Window
- Last 5 minutes
- Rule
- 5 matching errors
- Matching events
- 0
Not every failure appears as an unreachable URL. A worker may keep running while producing errors, or stop producing its usual activity altogether. Log monitors watch matching events within a time window so those conditions can receive attention.
Send logs through the JSON ingestion endpoint or supported OpenTelemetry HTTP/JSON format, then choose the service, levels and optional message text to count. Keep the rule focused enough that the resulting alert tells the team what changed.
Keep this signal alongside the rest of your stack: organize related services, choose who receives alerts and follow recovery in the same workspace. The goal is a check that explains what changed and gives the right person a useful place to start.
SMALL DETAILS. USEFUL CONTEXT.More than
More than
an up or down.
Purpose-built checks.
Information you can act on.
Choose the levels
Count the levels relevant to the rule, from trace through fatal, or include every level. An error-spike monitor and an activity monitor can watch the same service differently.
Match a message
Use optional, case-insensitive plain text to narrow the logs being counted. Focus on a recognizable failure message instead of treating every error as the same problem.
Thresholds over a window
Alert when matching logs reach your selected count within the lookback window. Evaluation runs every minute, with overlapping windows keeping recent events in context.
Watch for silence
Choose the no-matching-logs condition when activity should continue. A silent worker can need attention even when it has not emitted an explicit error.
Ingestion and usage detail
Manage log-source tokens and review daily usage in your workspace. Supported JSON and OpenTelemetry HTTP/JSON ingestion let you connect existing application tooling.
WHERE IT FITSMade for the work
Made for the work
you already do.
One reliable signal.
Plenty of practical uses.
Application error spikes
Watch the checkout service for repeated payment errors within five minutes. A focused count can highlight a pattern that would be easy to miss among routine messages.
Quiet background workers
Alert when expected activity disappears from a worker’s logs. Choose a window that matches normal idle time so ordinary pauses do not look like failures.
Operational messages
Track a specific recurring message with a plain-text filter. Keep log-based signals beside uptime and host metrics to investigate the application from several perspectives.
FROM SETUP TO A USEFUL SIGNALStart with what
Start with what
matters most.
Use a meaningful name, choose the behavior you expect and make sure the alert reaches someone who can act. Start with one service, then add the related checks as your monitoring grows.
Open the setup guide- 01
Choose your starting point.
Create a log-source token in Integration & API and send logs with a consistent service name using a supported ingestion format.
- 02
Configure the check.
Create a Logs monitor, choose the service, levels, optional message text and lookback window. Select a count threshold or silence condition.
- 03
Follow the signal.
Choose alerts and review the matching count, last received log and daily usage. Adjust the rule after observing the service’s normal volume.
A LITTLE MORE CONTEXTGood questions.
Good questions.
Clear answers.
The details that help you choose the right check and get a useful result.
Read the full documentationWhich plans include log monitoring?+
Log monitoring requires a plan with logs enabled; the standard Business plan includes it. Your workspace shows the available monitor count and daily ingestion allowance.
Can I use OpenTelemetry?+
The log ingestion endpoint supports OTLP over HTTP with a JSON body. Protobuf is not supported. Use the endpoint and settings shown in the documentation or workspace.
Are message filters regular expressions?+
No. The optional message filter is plain text and is not case-sensitive. Combine it with service and level selections to define the events you want to count.
How are log rules evaluated?+
Rules are evaluated every minute over the selected rolling window. After an error burst, recovery can take until enough events leave that window.
How long are logs retained?+
Logs are kept for seven days. Remove credentials and personal data before sending, and keep any separate records required by your own operational or retention needs.
LESS CHECKING. MORE KNOWING.One more thing
Get started One more thing
off your mind.
Bring log monitoring into your workspace.