Skip to content

Run a worker-built app in production

Running a worker-built app takes four things: alerts that reach a named owner, platform logs that are kept, scheduled backups with a restore someone has tested, and a usage check that feeds how to retire a worker-built app safely. How much of each you need depends on the app's risk tier, and who answers at each level is in the support model. Critical apps get IT's normal monitoring and on-call. As of October 2026.

Who this is for

App owners, IT operations staff and SREs who inherit worker-built apps they didn't build. You get what each tier needs to run, how to keep alerts reaching a real person, and the upkeep that stops an app quietly breaking. About 8 minutes.

What does each tier need to run?

The gate matrix is the only source for what each tier requires. The table reads it for operations, and adds the go-live checklist's good-practice lines, marked as such. A gate is required. Good practice is recommended and isn't enforced.

Need Sandbox Team Important Critical
Who answers the builder (self-supported) the builder plus a champion (team-supported) the owner, with a named backup who has run the app (assisted) IT or engineering with the business owner (IT-supported)
Written runbook not needed one-page app record (gate) runbook (gate) IT's standard documentation (gate)
Platform audit log on and kept not needed good practice good practice via IT's standard platform
Scheduled backups or exports not needed good practice good practice via IT's standard platform
Restore tested by someone other than the builder not needed a restore you've tested if an agent writes to live systems (never-do 4) good practice, dated in the record under IT's own service standards
Alert if the app stops or AI spend jumps not needed not needed good practice, to the registry's support route IT's normal monitoring and on-call
Exposure scan, repeated monthly not needed good practice gate gate
Scheduled review at 90 days every 12 months every 6 months every 6 months
Access review not needed good practice (app ownership), at the scheduled review good practice (app ownership), at the scheduled review quarterly (gate)
Availability promise none none none, unless the owner writes one IT's normal service levels

Sources: the operate and deploy gates, and the operations part of the go-live checklist. The monthly exposure scan isn't a row in the matrix. It comes from what the exposure scan must check and DR-0026. The access-review lines come from app ownership. The support levels and their response expectations are on the support model, so this page doesn't repeat them.

Scale it to business impact. A Team app that sorts one team's inbox doesn't need an uptime target, a pager or a restore drill. Promising one creates a promise nobody can staff. But "it's only internal" is the wrong test. An app that payroll or month-end close quietly depends on is Important or Critical under the Dependence question (Q4), whoever uses it, and it gets the columns to the right. Re-tier it when the dependence appears.

Don't: promise uptime for a Team app

A Team app is supported when the builder and a champion can get to it. A number like "99.9%" has nobody behind it, and users plan around promises. State the support level and let users keep their workaround (AP19).

How do alerts reach a real owner?

An alert helps only if a person who can act reads it. Most alert failures come from routing. When an alert turns out to be an incident, use incident response for AI-built apps, including who can contain an app out of hours.

  1. Send alerts to a role, not a person. Use the owner role's shared inbox or channel and the named backup, taken from the app registry. An alert sent to a leaver's inbox goes nowhere.
  2. Use what the platform already has. A scheduled test sign-in or an uptime check in IT's monitoring tool is enough for an Important app without a pipeline. For an app with an AI feature, add spend alerts on the provider or gateway (AI spend).
  3. Test the route at each scheduled review (twice a year from Important). Send a test alert and confirm that the owner and the backup both receive it.
  4. Let the registry find leavers. The monthly orphan and leaver checks in the registry health checks catch dead alert routes. When the builder leaves covers the handover itself.

Don't: route alerts to a builder's own inbox

When the builder moves on, the alerts stop reaching anyone and the app becomes an orphaned app (AP19)1.

Why does a tested restore matter?

A backup that has never been restored is a hope. A backup the app's own credential can delete isn't a backup either. In an April 2026 case reported in the press, a coding agent's single call deleted a production database volume and its volume-level backups in about nine seconds, and the host restored it in about half an hour2. In July 2025 an agent deleted a production database and then said rollback was impossible, though the rollback worked3.

  1. Keep a copy the app's credentials can't reach. Store backups or exports in a separate account or location, with write access limited to the backup job (AP4).
  2. Restore into a test copy and check the data is complete. Do it once before go-live, then at each scheduled review for Important apps (Critical follows IT's standards). The named backup does it, so the runbook gets exercised too.
  3. Date it in the record (last_restore_test_on).

Never-do 4 applies at every tier. An agent gets write access to live systems only after a sandbox run, with a scoped credential and a restore you've tested (the five never-dos).

Don't: skip the restore test

An untested restore tends to fail on the day you need it, and teams learn that during the incident (AP4).

What upkeep keeps an app working?

Apps also break when their surroundings change. Track each item below in the registry with an as-of date, and review it at the scheduled review.

  • Access reviews. List who can use and who can edit the app, plus every agent grant and token. Remove anyone who has changed roles. Critical apps do this quarterly. The rest do it at the scheduled review.
  • Platform and dependency changes. Read the hosting or low-code platform's change and end-of-support notices. Update libraries and connectors on the platform's schedule, and re-run the tier's tests afterward (change a worker-built app safely).
  • AI provider model retirements. Providers retire model versions on published dates. Record the pinned model and its retirement date in the registry (the version field on the AI sheet), and plan the switch with an eval re-run before the date. A retired model can stop the feature, and an automatic upgrade can change its behavior. As of October 2026 each provider publishes its own deprecation notices, and dates change, so check them at every review.
  • Exposure scans. The monthly scan from Important up confirms that data and URLs still need sign-in, because settings drift (what the scan must check).
  • Expiring credentials. Rotate on a schedule, and track the certificates, API keys and OAuth consents that expire. A key that lapses at 2 a.m. is an outage.

Don't: miss a provider's model retirement date

An AI feature pinned to a model its provider retires fails on the retirement date, or changes behavior when the provider upgrades it. Put the date in the registry and on the owner's calendar.

How do usage and cost signals feed retirement?

Once a quarter, ask one question: is anyone still using this? Pull the platform's last-used and active-user figures, compare them with the registry, and act.

Signal What it usually means Action
No use for 90 days Nobody needs it, or it broke and nobody said Ask the owner. If it's unneeded, start retirement
Users grew beyond the registered group Q2 may have changed Re-answer the six questions (when to re-tier)
AI or platform spend jumped A runaway loop, a new user group or a pricing change Follow AI spend, and pause the loop first
Retire-by date passed without renewal The decision was never made The owner renews with a reason, or retirement starts

What is the minimum runbook?

A runbook is a page the named backup can follow: how to restart, restore and roll back, what the alerts mean, and who to call. Start from the app record template and the document your app guide. Link it from the registry's runbook_link so the help desk finds it. When something breaks in a way that hurts, the steps are on incident response.

Assumptions and evidence

  • A-018 (Medium): we expect four support levels tied to the four risk tiers to be enough to set operating effort; test this by counting apps whose owner says they can't staff what their tier requires.
  • A-020 (Low): we expect orphaned apps to accumulate unless usage checks feed retirement; test this by comparing apps with no use in 90 days against retired apps each quarter.
  • A-027 (Medium): we expect AI spend under usage-based pricing to be volatile; test this by tracking month-on-month spend per app.

Evidence: two press-reported agent incidents, OWASP guidance and the site's own gate matrix; no controlled studies of operating worker-built apps. The good-practice lines are recommendations, not measured results. Facts on this page are as of October 2026.

  1. OWASP Citizen Development Top 10, CD-SEC-09 "Asset Management Failures" (2022; the orphan risk persists). https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures [primary], accessed 2026-10-21. ↩

  2. Decrypt, "AI Agent Deletes Startup's Database in 9 Seconds, Founder Says", Apr 2026 (news report; the primary post wasn't read). https://decrypt.co/365897/ai-agent-deletes-startup-database-9-seconds-founder-says [news], accessed 2026-10-21. ↩

  3. The Register, "Vibe coding service Replit deleted user's production database, faked data, told fibs galore", 21 Jul 2025. https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ [news], accessed 2026-10-21. ↩