# Daily Replicate usage and reliability digest in Slack > Every weekday at 7:50am, see how many model runs succeeded, which models are failing, and where your processing time actually went. - Workflow type: code - Services: Replicate, Slack, Google Sheets - Categories: Engineering, Operations - Published: 2026-08-09 ## What it does - Collects every model run from your Replicate account over the last 24 hours, however many pages of history that takes - Posts a Slack digest that leads with your overall failure rate and the single model that used the most processing time - Calls out any model failing more than 10 percent of its runs, so a broken model version gets caught the same day instead of next week - Adds one row per model per day to a Google Sheet, building the usage history you can chart over time ## What you'll need - A Replicate account that runs models regularly, connected with an access token you create in your Replicate account settings - A Slack workspace and the channel where you want the digest posted - A Google account and a spreadsheet with a tab set aside for the daily tracking history ## Prompt Every weekday at 7:50am, build me a Replicate usage and reliability digest, post it to Slack, and append the day's numbers to a Google Sheet so we accumulate a history we can chart. Start by pulling every prediction created in the last 24 hours using the Replicate List Predictions operation. This is a paginated list endpoint: it returns an object shaped { results: [...], next: , previous: }. Follow the full next URL, which carries an opaque cursor query param, to fetch the next page, and stop when next is null. Keep paging until the whole 24 hour window is covered, then filter the collected predictions to those whose created_at falls inside the window. Do not stop at the first page, because a busy account will have many pages and a partial pull would silently understate every number in the digest. Group the predictions two ways: by model and by status. Replicate status values are starting, processing, succeeded, failed, and canceled. For each model, count total runs and a breakdown of how many succeeded, failed, were canceled, and are still in flight (starting or processing). Sum total predict time per model from each prediction's metrics.predict_time, and also compute the average predict time per run. Some predictions will have no metrics.predict_time, for example ones that failed before the model started or that are still running, so treat a missing value as zero and never let it break the sum. Define the failure rate as failed divided by the number of finished runs, where finished means succeeded plus failed plus canceled. Predictions still in starting or processing are excluded from the rate and reported separately as a still running count, so an in flight run is never counted as either a success or a failure. Compute this both overall across the account and per model. Post the digest to a Slack channel using the Send a Message operation. Lead with the two headline numbers: the overall failure rate for the window (with the raw failed and finished counts in parentheses) and the single model that burned the most total predict time, including its second count and run count. Then explicitly call out every model whose failure rate is above 10 percent, listing each one with its failure rate, its failed and finished counts, and its total predict time. Follow that with a per model table showing run counts, the status breakdown, and total predict time, sorted by predict time descending. If no model is above the threshold, say so in one line rather than omitting the section, and if there were no predictions at all in the window, still post a short message saying zero runs were recorded so a quiet day is never confused with a broken workflow. Then append one row per model per day to a tracking tab in Google Sheets using the Append Values operation. Each row should carry the date of the window, the model identifier, total runs, succeeded, failed, canceled, still running, the failure rate, total predict time in seconds, and average predict time per run. Append only, never overwrite earlier rows, because the whole point is the accumulating history that lets us chart failure rates and predict time per model over weeks. Keep every number factual. A Replicate prediction object has no cost field, so report run counts and predict time as the spend proxy and never fabricate dollar estimates, per unit pricing, or projected monthly costs. If a figure cannot be computed from the prediction data, leave it out rather than guessing. ## How to customize - Change the timing or the days it runs, for example every morning including weekends, or twice a day if you run models around the clock - Point the digest at a different Slack channel, or send it as a direct message to whoever owns model quality - Move the 10 percent failure threshold up or down, and widen the window from 24 hours to a full week for a Monday recap ## Example output Replicate daily digest, Fri 8 Aug 142 runs in the last 24 hours. Failure rate 11.3 percent (16 failed of 141 finished). 1 still processing. Most processing time: black-forest-labs/flux-dev, 3,412s across 58 runs. Above the 10 percent threshold: - stability-ai/sdxl, 34.8 percent failed (8 of 23 finished), 612s total - meta/musicgen, 15.0 percent failed (3 of 20 finished), 488s total By model: black-forest-labs/flux-dev 58 runs 57 succeeded 1 failed 0 canceled 3,412s stability-ai/sdxl 23 runs 14 succeeded 8 failed 1 canceled 612s meta/musicgen 20 runs 17 succeeded 3 failed 0 canceled 488s openai/whisper 41 runs 37 succeeded 4 failed 0 canceled 301s ## FAQ ### Does this tell me how much I spent on Replicate? No, and that is deliberate. Replicate does not attach a dollar amount to an individual run, so the digest reports run counts and total processing time instead. Those are the honest signals for where usage is concentrated, and you will never get a made up cost estimate. ### What if I run thousands of predictions a day? That is fine. The workflow walks through your full run history in batches until it has covered the entire 24 hour window, so a busy account gets the same complete picture as a quiet one. ### How is the failure rate calculated? It is the share of finished runs that failed. Runs that were still starting or processing when the digest ran are counted and reported separately, so they never quietly inflate or deflate the rate. ### Will it still post if nothing went wrong? Yes. You get the digest every weekday either way, with the failure rate and the busiest model, and the section for models above the threshold simply says there were none. A silent day and a broken workflow should never look the same. ### Do I need Slack and Google Sheets, or can I use just one? You can run either half on its own. The Slack digest is the daily read and the spreadsheet is the long term history you chart from, but the workflow works fine if you only want one of them. Use this prompt in General Input: https://www.generalinput.com/prompts/daily-replicate-usage-and-reliability-digest-in-slack