01
Work with your monitoring data.
Use bearer authentication and a key with the permissions your integration needs. Follow the reference for supported endpoints.
Explore the REST API FOR DEVELOPERSYou build the service.
You build the service.
Keep its signals close.
Start with a health endpoint. Add a successful-job check-in and the application events that matter. Connect your monitoring workflow through the REST API, with clear permissions and documented request formats.
Monitor types and allowances depend on your plan. View plansworkspace / background work
API · /healthStatus and response rules
PassingWorker · nightly exportExpected successful check-in
Late check-inHost · worker-01Infrastructure context
HealthyLogs · applicationConfigured error rule
No matchesA running process is not always a completed job.
A web service can answer requests while its worker has stopped producing useful results. Monitor each behavior on its own terms: an expected API response, a successful-job check-in or a focused rule around application logs.
02
Check in after successful work.
Add heartbeat calls to scheduled scripts and workers. Set an expected interval and grace period that match the job.
Explore heartbeat monitoring03
Turn selected events into a signal.
Send supported JSON or OTLP/HTTP log data and configure focused error or missing-activity rules within your plan's limits.
Explore log monitoring04
Make health checks meaningful.
Validate status, latency and supported JSON or header rules. Use a response that reflects the dependency you care about.
Explore API checksA WORKFLOW YOU CAN MAKE YOUR OWNREST API · Read your monitors
Add monitoring where the work happens.
Start with a useful signal. Make ownership clear. Check how failures and recovery reach the people who need to act.
Find your setup guidecurl --fail --silent --show-error \
"https://uptiva.linuxmaster.cloud/api/monitors" \
-H "Authorization: Bearer $UPTIVA_API_KEY"Example request. Use a key with read access and follow the authentication guide .
- 01
Define a useful success signal.
Choose what the check should prove: an expected response, a successful job run or the presence of an application event.
- 02
Connect with the right credentials.
Use the documented authentication for each integration. API keys, heartbeat URLs and log-ingestion tokens have different purposes.
- 03
Verify the failure path.
Test how a failed response or missed check-in appears, then confirm alert recipients and recovery behavior before relying on it.
YOUR FIRST FEW SIGNALSA practical
A practical
starting point.
Add coverage in useful steps.
Keep each check understandable.
BEFORE YOU GET STARTEDA little context.
A little context.
Clearer decisions.
Practical answers for choosing the checks and workflow that fit.
Browse the documentationCan I automate monitoring through the REST API?+
Yes. Uptiva provides documented REST endpoints and bearer API keys with read-only or read-write access. API-key availability depends on your plan, and not every browser-only action is available to API keys. Use the public API reference for supported operations.
When should a script send its heartbeat?+
Send the successful check-in after the work you want to monitor has completed successfully. Set an interval and grace period that account for normal scheduling and runtime variation.
Do logs and heartbeats use the same API key?+
No. General REST API keys, heartbeat check-in URLs and log-ingestion tokens serve different purposes. Follow the documentation for each integration and keep its credentials out of public pages and source control.
Are logs included in every plan?+
No. Log ingestion and related allowances depend on your plan. Check the current pricing and workspace limits before designing an integration around logs.
Is the MCP server available?+
The MCP integration is planned. Use the available REST API and its documentation for current integrations.
START WITH ONE IMPORTANT SERVICEA clearer view.
A clearer view.
For your kind of work.
Choose your first check. Build the context around it.