Combine a long-running command with an Android notification
Get an Android notification when your command finishes, so you can step away while it runs.
Prepare
An interactive Bash session and curl on Linux or macOS. With set -e, a failed command may stop before notifying. This short example does not preserve the command exit code.
Install QueueRing on Android, register the device, allow notifications, and copy the current Queue ID. Keep the phone online.
Keep your Queue ID private; reissue it in the app if exposed. Use a trusted machine without shell tracing (set -x) or terminal recording.
Use the Bash recipe to report success/failure and preserve exit codes
1. Set your Queue ID
Use a terminal with Bash and curl. Allow notifications in the QueueRing Android app, then paste the Queue ID from the app at the prompt below. Input is hidden. Use the same terminal for all three steps.
read -r -s -p "Queue ID: " QUEUE_ID; echo2. Test the connection
curl -X POST \
-H "Content-Type: text/plain; charset=utf-8" \
-d "Task finished" \
"https://api.queuering.org/q/$QUEUE_ID"Once Task finished appears on Android, continue to the next step.
3. Combine it with a long-running command
sleep 10; curl -X POST \
-H "Content-Type: text/plain; charset=utf-8" \
-d "Task finished" \
"https://api.queuering.org/q/$QUEUE_ID"Replace sleep 10 with your actual command, such as a build.
Verify on your device
Check for Task finished on Android. The semicolon sends after success or failure in a normal interactive Bash session. Forced termination, host shutdown, and hangs are not detected.
If HTTP 202 arrives without a phone alert, verify the current Queue ID, Android notification permission, and device connectivity first. Check the app's recent history as an additional observation, not a delivery receipt.
Notes and further examples
202 only means accepted; display, history, and ID validity are not guaranteed. Resends can duplicate alerts; retry the notification only, never the job or agent. HTTP errors and retry advice.
Copy buttons copy code only. If unavailable, select the code and copy manually. Code messages are shared with the English examples.
Queue ID security details
Keep the Queue ID private
A Queue ID grants permission to send notifications to your device: treat it as a bearer credential. Never put a real ID in public repositories, Issues, logs, screenshots, prompts, or fixed sample values. Do not use shell tracing (set -x), curl verbose/trace output, or shared terminal recordings. The URL and process arguments can contain the ID; run only on a trusted machine and restrict proxy/access logs.
If exposed, reissue/rotate the Queue ID in the app and replace every local configuration or Actions secret using the old ID. Copy the new value from the app rather than editing the old one. A 202 response cannot confirm that an old ID remains valid.
API contract, HTTP errors, and retries
Understand the response and retry safely
Notifications and message history are best-effort. HTTP 202 means request acceptance, not guaranteed display on Android or guaranteed history storage. Invalid, inactive, and outdated Queue IDs intentionally receive the same 202 response. History stores up to 100 messages captured on the device; absence from history alone does not establish an HTTP failure.
The endpoint is POST https://api.queuering.org/q/{queueId}. Use UTF-8 text/plain; charset=utf-8, or application/json with a required nonempty body string and optional nonblank title. The raw request body, including JSON syntax, must be at most 4096 bytes.
| Result | What to do |
|---|---|
| 202 | Check Android notification permissions, connectivity, and the current ID in the app. Do not retry merely because no notification appears. |
| 400 | Fix the request, Content-Type, JSON syntax, and required fields before resending. |
| 413 | Shorten the UTF-8 body to 4096 bytes or less; JSON escaping also counts. |
| 429 | Wait at least Retry-After seconds when provided. If absent, use a delayed bounded retry with backoff rather than a tight loop. |
| 503 | Temporarily unavailable. Inspect the failure and retry later with bounded backoff. |
| Transport failure / timeout | The outcome may be unknown. Check connectivity before deciding to resend. |
The detailed curl example and operational senders send once, with a 10-second connect timeout and 30-second total timeout. The short curl and long-running command examples do not set timeouts. The detailed examples print HTTP status and response headers (including Retry-After); none of these examples automatically retry. Resending can create duplicate alerts; there is no idempotency key in these examples. Retry the notification only, never rerun a backup, deployment, or agent just to send its status. Keep your normal job logs and monitoring as the source of truth.