Upbuild
Upbuild / AI Alerts
AI alerts
Describe a budget, naming or tracking guardrail in one sentence. Upbuild checks it on every refresh, across every account the rule names, and tells the people who can act while it is still cheap to fix.
Why it belongs here
Upbuild reads the accounts you connect on a cadence you set: every 30 minutes, every 60, or once a day, in your organisation's own timezone. Each read is a data stream, a named request with a window, an account and a destination. The rows arrive whether anybody opens the dashboard or not.
So a guardrail is not a new pipeline. It is a condition checked against a stream already being fetched, on a clock already running. That is why alerting sits beside the dashboards and the exports, instead of arriving as a tool with its own connectors, credentials and invoice.
Operational alerts
Campaign guardrails are the ones you write. Alongside them Upbuild raises four of its own accord, about the health of what it runs, addressed to the organisation's admins. A dashboard that stops refreshing is as worth hearing about as a campaign that overspends.
A failing dashboard mails the admins and its builder once a day, however many refreshes fail. A connection waits for three failed probes, about half an hour: one timeout is not news.
Each mail carries what the platform returned, when the dashboard last had good data, and a link to the thing itself. Re-authorising takes seconds and changes nothing you built.
Operational only: dashboards, connections and trial, addressed to the organisation's admins.
| What triggers it | State | |
|---|---|---|
| A dashboard has stopped refreshingdashboard_failing | An error, and no good data for three refresh windows | LIVE |
| A dashboard is not drawingdashboard_render_error | The version people open threw, or drew nothing | LIVE |
| A connection needs re-authorisingconnection_down | Three failed probes in a row | LIVE |
| The trial is endingtrial_ending | Ten, five, two and one day out, and on the day | LIVE |
Campaign guardrails
One sentence per guardrail, checked on every refresh, across every account the rule names. Three families cover almost everything people ask for: budget and pacing, naming conventions, and tracking. You write them in the same composer you use to change a dashboard or a schedule.
A campaign burning its month in a week. A market pacing ahead of plan. A line paused a fortnight ago and still spending. The check reads the rows the dashboards draw, so the two can never disagree.
A campaign that breaks the convention, a tag that stopped recording, a conversion that vanished overnight. Upbuild reads tag containers and analytics properties, and writes nothing back to any of them.
One rule, the stream it reads, the clock it rides and the person it tells.
How it works
A guardrail is written once and then does its own work. There is nothing to schedule, nothing to maintain, and no second set of numbers to reconcile against the dashboards.
One sentence, in the composer you already use to change a dashboard or a schedule. No query language, no threshold matrix, no per-account copy of it.
Each time the stream behind it is fetched, the condition is checked against the rows that arrived. No second pipeline, no second set of numbers to reconcile.
The person or group named on the rule, with the account, the number and a link. Once per breach, not once per refresh, the way the operational mails behave.
Straight answers
Once per breach, not once per refresh. A campaign that sits over its threshold for a fortnight is one mail, not sixty. The operational alerts behave the same way: a failing dashboard writes once a day however many refreshes fail, and a connection waits for three failed probes before it says anything, because one timeout is not news.
No. Every tool that touches an advertising platform is read-only, guardrails included. A guardrail tells a person something is wrong, with the account and the number in front of them. It never pauses a campaign or moves a budget itself. The decision stays with someone who can make it.
Get in touch