A build finishes. A deployment completes. Your app reaches a useful milestone. A small display on your desk can keep that result visible while you get on with the next piece of work.
TickrMeter hosts the display app and renders its screen. Your existing build workflow sends the result. Once you’ve connected your account, created a layout and selected your device, the ongoing job is a small data push from your code.
This example uses the last completed build. Your AI assistant can help create the hosted layout and the publisher that sends that result to TickrMeter.
Choose exactly what the screen means
“App status” can mean several different things. A successful build does not prove a deployment succeeded, and a successful deployment does not prove the app is healthy. Pick one signal and give it an honest label.
For this example, show your app’s name, Last completed build, and a text value: PASSED, FAILED or UNKNOWN. Add the source observation timestamp, labelled Build completed, so you can see when the result came from. UNKNOWN is useful when the source explicitly has no known result; it should not disguise a failed request.
You’ll need a TickrMeter account, a configured device, access to the build result, and a place to run the publishing step. That could be your existing build workflow or a persistent collector. An AI client connected through MCP is useful for creating the layout and code; the data push itself uses the display’s API connection.
Ask for the layout and a publisher
Open Apps → Custom display → Use TickrMeter hosting → Create with your AI. Follow the client connection instructions, then paste the portal’s generated instructions into your assistant. Add this prompt, replacing the bracketed details:
Create a hosted TickrMeter display for the last completed build of
[my app name]. Show the app name and “Last completed build”. Use a manual
text field for PASSED, FAILED or UNKNOWN. Include a source-observation
Timestamp block labelled “Build completed”, using UTC. Do not substitute
the built-in clock for that timestamp. Keep the layout editable.
My build runs in [describe the actual workflow or command]. First inspect
how it reports completion and failure. Do not assume a native integration.
Write a small publisher that reads the actual completed result and time,
then sends them using this saved display’s schema and snapshot endpoint.
Use the real generated field key, and send every manual field each time.
Keep the producer token in the workflow’s secret settings or an environment
variable. Never put it in browser code, a commit or a log.
Keep synthetic samples in a separate new, unattached test display.
Include error handling and instructions for where this publisher runs.
Do not change my deployment or send to a physical device yet.Review the assistant’s proposed change before installing it. In particular, check that it observes a failed build too. A publishing step that only runs after success cannot tell you about the failure you most wanted to notice.
Connect the data to the saved display
Open the saved display’s data-connection area. Use its exact snapshot endpoint, producer token and generated schema. The token writes to that display; keep it in your runtime’s secret storage. The quickstart shows the request format, and the REST reference documents the endpoint.
Send the text value under values, with the actual source observation time in observedAt. Use the build’s completion time for this recipe. Each snapshot replaces the manual values, so include every manual field in the layout rather than treating a request as a partial update.
Use a separate, unattached test display for synthetic samples. In the real setup, send a completed build with its actual completion time. Snapshot timestamps cannot go backwards: if a setup already contains a newer sample, test with a newly completed build. Never change an old build’s timestamp to make it pass.
Use the observation Timestamp block to show when the build completed. Built-in Time and Date blocks describe the time the image was generated; they do not establish how fresh your source data is. A new preview must not make yesterday’s result look like today’s build.
Keep the source running
Your publisher can live in the build workflow you already run. It supplies values while TickrMeter hosts the display app and handles rendering. If you use a separate collector, put it somewhere that stays available. A script on a sleeping laptop takes the same break as the laptop.
Preserve the meaning of the data when something goes wrong. A failed read is not a failed build, and neither should silently become a successful result. Retain the last valid observation time, handle the source error, and give yourself a way to notice a stalled publisher. See errors and recovery for the API side.
Check the preview and the desk
Choose Refresh preview, inspect the value, then select your device, choose LED brightness and press Send to TickrMeter. Check the physical screen. A stored snapshot is not confirmation that the device has displayed it.
Use this as a glanceable record of the last result. Keep your build notifications and monitoring for time-sensitive failures. Once the simple version works, the same pattern can take an actual deployment result or another signal your app already produces. The custom-display guide explains the hosted route and its alternatives.
