Backup plans and ping URLs

ServerMetry monitors reports from your backup scripts. It does not run backups or test restores.

Set up plans and jobs

Open Backup plans and select a plan. Its detail page has Overview, Jobs, Backup history, and Settings tabs. Settings contains the plan ping URL and confirmed deletion. Unsaved inputs survive tab changes. Plans and jobs can reference servers, services, or websites. A website does not need a server assignment.

Create a job for each separate backup operation. Enable monitoring and set a five-field cron schedule, time zone, and grace period in minutes. With monitoring disabled, reports remain visible, but backup rules do not alert for that job.

Each plan and each job has its own secret ping URL. A plan ping does not confirm its jobs. Rules evaluate the jobs when a plan has jobs. For plans without jobs, the expected interval in hours controls monitoring.

Sort tables

In the backup plan table, click Name, Status, or Last completion to sort. Subjobs also support sorting by Monitoring. Click again to reverse the order; an arrow shows the current direction. Use Tab and Enter or Space to operate the column headers with a keyboard.

Monitoring puts enabled subjobs first on the first click; Last completion puts the newest completions first. Entries without a completion stay at the end in both directions. Sorting applies to the entire loaded list before pagination into groups of 25. Search and sorting work together; changing either returns to page 1. Status is sorted by its displayed, translated text. Backup history supports sorting by status, start and completion across all matching pages. Missing timestamps remain last. Changing the sort returns to page 1.

Connection and help

Once a plan or one of its jobs receives a report, the interface shows Online backup · With checks beside the result status, such as Successful or Warning. This confirms receipt of backup reports, not recoverability or continuous availability. Before any report, it shows Documented.

Schedule monitoring is separate. Schedule monitoring off means reports and durations are recorded, but backup rules do not send alerts for this job. “Last completion” also includes the plan’s jobs; a start is not a completion. Open explanations for schedules, ping URLs and Coolify with the question-mark buttons using a click, touch or keyboard.

Running backups and runtime limits

After /start, the job and plan show Running. For parallel runs, the overview shows the number of open runs and the time since the oldest start. Backup history updates each open run’s duration. Success, warning or failure completes the corresponding run. Always use a unique runId for the start and completion of parallel backups.

Open runs have an automatic timeout of 120 minutes by default. For an earlier alert, enable monitoring with a valid schedule on the job and create an enabled Running too long rule under Rules → Backup, for example 60 minutes, with a notification channel. Evaluation runs every minute and respects the configured alert delay. Without enabled monitoring and a matching rule, no runtime alert is sent.

Evaluation checks the oldest still-open run, even when a newer parallel run succeeded. Once the runtime alert is active, the plan and job show Runtime exceeded as an error state. Until the automatic timeout, the run remains open and accepts completion with the same runId. At timeout, only the monitored run is closed as failed; the external backup process is not stopped. The runtime alert clears once no open run exceeds the limit, or monitoring/the rule is disabled. A new successful execution alone does not close an older open run.

Coolify does not send a start event, so its normal webhooks cannot trigger runtime alerts. Use overdue rules to detect missing results instead.

GET and POST

Both methods use the host https://api.servermetry.com and the path /api/v1/backup/ping/<token>. On Dev, use https://dev-api.servermetry.com. Copy the full URL from the dashboard. No session cookie or API key is required. Anyone with this URL can report results. Keep it secret.

Method and URL	Status source	Extra data
GET base URL	status query parameter; default success	runId, message, sizeBytes query parameters
POST base URL	JSON status; default success	JSON body
GET /<event>	URL suffix	Query parameters
POST /<event>	URL suffix	JSON body

Suffix	Result
/start	Starts a run
/success or /0	Completes a successful run
/warning	Completes a run with warnings
/fail or /failure	Completes a failed run
/1 through /255	Failure; default message Exit code N

GET also accepts status=fail. JSON status accepts only start, success, warning, or failure. With a URL suffix, the suffix sets the status; omit status from the body. An empty POST body is valid. Send JSON with Content-Type: application/json, not form data. GET reads query parameters; POST reads the body.

POST fields

All fields are optional.

Field	Type and limit	Purpose
status	start, success, warning, failure; default success	Sets a non-success result on the base URL
runId	1–100 characters after trimming; A–Z/a–z, digits, _, ., :, -	Connects the start and result of one run
message	Text, maximum 500 characters	Backup history message; overrides the exit-code default message
sizeBytes	Number, at least 0	Backup size in bytes

GET accepts the same extra fields. Encode URL text, for example with curl --get --data-urlencode.

Measure duration

Send start, then a result with the same runId. Use a new ID for each execution, especially for parallel backups. Duration uses the server receipt times of start and result. You cannot submit a custom duration.

PING_URL='https://api.servermetry.com/api/v1/backup/ping/<token>'
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)-$$"
curl -fsS --max-time 10 --retry 3 --get \
  --data-urlencode "runId=$RUN_ID" "$PING_URL/start"
if /usr/local/bin/backup.sh; then
  RESULT=0
else
  RESULT=$?
fi
curl -fsS --max-time 10 --retry 3 --get \
  --data-urlencode "runId=$RUN_ID" "$PING_URL/$RESULT"
exit "$RESULT"

The script saves the exit code immediately. A later command would replace $?. This example treats every nonzero exit code as failure. To report a warning, your script must send warning explicitly.

A POST result, after a start with the same ID:

curl -fsS --max-time 10 -X POST \
  -H 'Content-Type: application/json' \
  -d '{"status":"warning","runId":"nightly-2026-10-22","message":"3 files skipped","sizeBytes":1048576}' \
  'https://api.servermetry.com/api/v1/backup/ping/<token>'

Without runId, a result closes the most recently started open run. A result without a start is stored without measured duration. A completed explicit ID cannot be changed: retries do not create a second run. Use a fresh ID for the next execution. A late result for an older parallel run remains in history but does not replace the newest run's status. Each target retains its last 500 completed runs. Open runs are not removed by history retention.

Warnings and rules

Under Rules → New rule → Backup, select all backups, specific plans, or individual jobs, then select notification channels. Monitoring must be active for the target.

Condition	Trigger
Failed (FAILED)	Failure status
Finished with warnings (WARNING)	Warning status
Overdue (OVERDUE)	Scheduled completion plus grace period without success or warning
Running too long (RUNNING_TOO_LONG)	At least one run remains open after start beyond the configured limit

A warning counts as a completed backup for the current schedule. It does not prevent a later overdue state. Failure takes priority over overdue; overdue takes priority over warning. The run status WARNING is separate from rule severity (WARNING or CRITICAL).

Rules are evaluated every minute. Any configured alert delay must also expire. An ongoing problem does not send a new alert each minute. Recovery sends a resolution notification. See Notifications for channel settings.

Rotate a URL and check errors

On the detail page, select Show URL → Regenerate URL for the plan or job. The old URL becomes invalid. Schedule and history remain. Update your script after rotation.

HTTP status	Meaning
200	Ping accepted, including a repeated completed runId
400	Invalid JSON, invalid field, or unknown URL suffix
404	Unknown or rotated token, or deleted target
429	The target already has 20 open runs; complete existing runs first

Under Show URL → Report start, result and duration, job examples use the actual job URL. A green status confirms the script report, not backup integrity or restore capability.

Coolify database backups

The optional Coolify controls and secret URL are visible only to organization admins and owners.

Create a plan, for example Coolify, with one job for each database. Open Jobs → open job → Settings → Connect Coolify (optional) and select Enable webhook. Enter the database UUID for this job. Leave this optional area closed for backups without Coolify. There is one secret webhook URL per organization; jobs in different plans share it.

Assign each job its database UUID from Coolify. Names are not UUIDs. Each database can map to one job. Multiple schedules for the same database share that job's results; use an appropriate monitoring schedule. Separate organizations are required if different Coolify instances use the same database UUID.

In Coolify, open Notifications → Webhook, enter this central URL, enable the channel, and select Backup Success and Backup Failure. Check existing team webhooks before replacing a URL. Send test confirms delivery without creating a backup run. Then run a database backup and check the corresponding job's history.

Coolify event	ServerMetry result
backup_success	Success
backup_failed	Failure
backup_success_with_s3_warning	Warning: local backup exists, S3 upload failed
test or other events	No backup run

The receiver accepts JSON POST requests at /api/v1/backup/coolify/<token>. Backup events require database_uuid. The event field determines the result, not the success boolean. Unknown receivers or databases return 404, invalid or missing fields return 400, and payloads above 16 KiB return 413. It never follows a URL from the payload or stores the original vendor logs. Coolify does not retry every non-2xx HTTP response: verify actual delivery and run history after setup.

Duration: Native Coolify webhooks have no start signal or execution ID. Runs have a completion time, but no start time or duration. Identical consecutive events (event, database UUID and message) are combined for 60 seconds. This can combine two real identical backups within that window; late retries may create another run. A changed result is recorded immediately.

Enable monitoring on each job and set its cron schedule, timezone and tolerance. Add failure, warning and overdue rules under Rules → Backup, then choose the notification channels. A mapping alone does not enable alarms. Without a start signal, a runtime rule cannot detect a long-running native Coolify backup.

Regenerate webhook URL requires confirmation, invalidates the old URL and keeps all mappings and history. Update every Coolify sender for this organization afterwards. Regenerating a separate normal job ping URL does not affect the central Coolify integration. Removing a mapping stops further results for that database; deleting a job also removes its mapping.

See the official Coolify payload reference and notification setup.

ZeroByte

Create one ServerMetry job for each ZeroByte backup job. Set its actual schedule and timezone, then enable monitoring with a suitable tolerance.

Use the job ping URL, not the plan URL or central Coolify URL. In ZeroByte, configure a separate HTTP GET destination for each event and assign it to the matching backup job:

ZeroByte event	Destination URL
Start	<JOB-PING-URL>/start
Success	<JOB-PING-URL>/success
Warning	<JOB-PING-URL>/warning
Failure	<JOB-PING-URL>/failure

Each destination must respond only to its matching event. Keep existing email or other notifications. Start and completion together measure duration; these simple GET destinations do not transmit detailed backup logs or sizes.

Configure the required alarm rules in ServerMetry separately. Run a real ZeroByte backup and check the result and duration on the correct job. After regenerating a job ping URL, update all four matching destinations.

WordPress and UpdraftPlus

Open Settings → Integrations for the plugin download and setup steps for WordPress and Coolify. On mobile, use the Settings icon in the header. Coolify mappings remain on the individual backup job.

Under Plugins → Add New, search for ServerMetry Backup Monitoring and install it. You can also download the ZIP from WordPress.org and upload it. Enable it, then select Settings in the plugin list or open Settings → ServerMetry. The plugin list also includes a documentation link. When all saved ping URLs target Dev, the plugin dashboard links also target Dev. Updates appear under Plugins in WordPress; saved URLs are retained during updates. Requires PHP 7.4+ and WordPress 6.0+; the hook contract was checked against UpdraftPlus 1.26.13.

Enter a normal job ping URL (/api/v1/backup/ping/...), not the central Coolify webhook URL. You can use one default URL, or separate file and database job URLs. A combined backup reports to both distinct targets; its duration is the whole backup duration, not each internal phase.

The plugin reports start, success, warning and final failure/abort. Retries within UpdraftPlus remain the same run. It sends a stable run ID and short status messages; no raw logs, passwords, backup contents or backup size. It does not create ServerMetry plans or alarm rules and does not change UpdraftPlus schedules or email settings.

Blank URL fields keep stored values; use the explicit remove option to clear a URL. Treat these URLs as secrets: they remain in the WordPress options database and can appear in database backups. Failed final deliveries have up to three WP-Cron retries. WP-Cron needs site traffic or an external cron trigger. A hard process exit can prevent a final event, so configure overdue and runtime rules too. A live backup on your WordPress installation still needs a separate test.

External service and privacy: Saving a ping URL enables reports to the configured ServerMetry endpoint. In addition to status and run ID, backup starts include file/database intervals and next UTC timestamps. The receiver sees the server IP; the WordPress HTTP user agent can include the WordPress version and site URL. See the terms of use and privacy policy. Without a configured URL, the plugin starts no new reports. Existing runs retain their original targets.

Permanent removal: Uninstalling retains settings, last-delivery information and pending run options/cron entries. Cleanup cannot run while the plugin is inactive; reinstalling can resume pending reports. Let outstanding runs finish, remove saved URLs and rotate the ping URL in ServerMetry to revoke the old token immediately. ServerMetry history is retained.

Schedule suggestions for jobs

Open Jobs → open job → Settings → Schedule suggestion to review a detected schedule. Apply suggestion fills the cron expression, timezone and grace period in the form; only Save changes the job. Monitoring and notification rules remain separate settings. The UpdraftPlus schedule is not changed. Schedule from another job copies an existing schedule from a job in the same plan.

WordPress plugin 0.1.2 reports the configured WP-Cron file and database intervals and next timestamps on the next backup start. A shared target with different schedules receives no misleading combined suggestion. Use separate jobs and the separate plugin URL fields. UpdraftPlus setting changes are reported on the next new start. Manual or missing schedules are explicit. Custom Premium schedules and incremental backups require separate review.

Without a reported schedule, detection requires at least five regular runs. It examines up to 24 recent runs and uses at most the last twelve start times. Completion times are used only if no starts exist. Missing, additional, irregular or stale runs produce no suggestion. This also applies to Coolify: only completion timing is observed, not the configured schedule or start time.

Supported fixed intervals: 1, 2, 3, 4, 6, 8, 12 and 24 hours, and seven days. Fortnightly and monthly intervals are not converted into inaccurate cron expressions. Suggestions use UTC, matching fixed WP-Cron intervals; local time can shift at daylight saving changes. WP-Cron can run late when the site has no traffic. Review the suggestion and grace period before enabling monitoring. Existing plugin versions and ping URLs remain compatible.

Subjobs and backup history

The Jobs tab uses a compact table with search and 25 entries per page. It shows name, state, monitoring and last completion. On narrow screens the table scrolls horizontally and hides the monitoring column.

Click a name or row to open the subjob's own page. Overview contains its description, targets, schedule and revealable ping URL. Settings contains schedule suggestions, the optional Coolify connection and an explicit save action. Deleting is only available at the bottom of this view and requires confirmation. The back link returns directly to the subjob table. Add subjob opens a dedicated creation page.

Backup history shows subjob, result, start, completion and duration in a table with 25 runs per page. Filter the plan's history by subjob; changing the filter starts at the first page. The details button reveals the run ID, original message and reported size. Technical run IDs and user-defined names are not translated. Start and completion use the selected interface language and the browser's local timezone. A missing start leaves duration blank; active runs show elapsed time. The first page refreshes every 15 seconds, while older pages remain stable for reading.

Automatic run timeout

A run opened with start is automatically recorded as failed after 120 minutes without completion by default. Backup history shows a timeout message; its finish time and duration stop at that deadline. The check runs every minute. After an API outage, the next successful sweep also closes old open runs. A large backlog can take several minutes because each sweep processes a bounded batch.

This applies to plan and job ping URLs, even with monitoring and alert rules disabled. It does not stop the actual backup process. Operators can set BACKUP_RUN_TIMEOUT_MINUTES to an integer from 1 to 10080 for the whole instance and restart the API. Missing or invalid values use 120 minutes. Increase this limit before running longer backups.

A timeout is neither a received ping nor a successful backup. A newer successful run remains the current target status while an older timeout stays in history. With an explicit runId, a late completion after timeout is ignored, as for other completed runs. Use a new ID for the next run. Without runId, a late completion cannot be linked to an already expired run and follows the normal ping rules.

Notifications require enabled monitoring and a matching Failed rule. It reacts when the newest run times out; an older overlapping timeout does not replace a newer success. A Running too long rule can warn before the timeout. Once the run expires it is no longer open, so that rule can recover while the failure rule fires. A timeout does not enable notifications automatically.