Not yet released. This guide describes implemented changes awaiting rollout. Availability requires the corresponding backend and dashboard release.
Goal
Know what Stackie is watching, what it did on its own, and what is waiting for you, from one place.Prerequisites
- A StackShift account. Watching and reports are free on every account.
- A paid plan, if you want Stackie to fix things itself.
Workflow
1
Open Hosting › Health. The top of the page shows the one thing Stackie fixed or needs from you, with the facts it checked.
2
Read “What Stackie watches” to see each product Stackie covers, what it looks for and what it does when it finds a problem.
3
Turn on “On Call for everything” in Agents › Stackie to let Stackie fix things itself, within how much Stackie does on its own.
4
Change a single project in its Settings › Health: follow your account, only tell you, or follow Stackie’s level.
What Stackie watches
- Apps: crash loops, server errors, slow pages and traffic that stops. Stackie rolls back a bad release or restarts the app, then checks it held.
- Builds: a deploy that fails to build. Stackie finds why and, when the fix is in your code, gets a pull request ready for you to review. It never merges its own fix.
- Domains and padlocks: padlocks close to their end, and records changed at your domain company. Stackie renews padlocks. If your records are at another company it tells you the exact record to change; if StackShift manages them, it can put the record back with your OK.
- Databases: storage filling up, too many connections, failed backups, a standby falling behind, a database that didn’t wake. Stackie retries backups and turns on connection pooling when it’s free; more storage waits for you because it costs money.
- Servers: full disks, memory pressure and servers that stop answering. A restart always waits for your OK.
- Mail sending: bounces, complaints and blocklists. Stackie pauses the campaigns from that domain to protect your name, then tells you. You resume them from Mail.
- Mailboxes, storage, scheduled jobs, mobile builds and sandboxes: mail that stops arriving, full mailboxes, storage near its limit, a job that fails three times in a row (Stackie can turn it off), failed mobile builds, and sandboxes left running with nothing to do (Stackie puts them to sleep).
What happens when Stackie finds something
Stackie checks the usual causes first: a recent deploy, changed settings, the database, the disk and the logs. When your account has AI credits it can also look deeper, once per problem and up to your On Call daily limit in Agents › Stackie. Without credits you still get the checks and the fix it would make. If your rules allow the fix, Stackie makes it, watches for a while to make sure the problem is gone, and records it in Everything agents did. If the fix didn’t hold, Stackie undoes it where it can and asks you. Otherwise it gets the change ready and asks you once, in the bell and by email.- Approve from the email link only for safe changes, like a restart or a roll back. Anything that costs money, deletes data or changes who can reach you opens the dashboard and needs you signed in.
- Email links last 15 minutes and stop working if your app changed since they were sent.
- “Remind me tomorrow” brings the item back in the bell and by email after 24 hours.
- Every Monday you get a short email: what Stackie fixed and what needed you.
From the command line
An access token can read On Call and turn it off. Only you, signed in to the dashboard, can turn it on.Expected result
You hear about problems before your users do, safe fixes happen on their own and are checked, and anything that costs money, touches your data or reaches people waits for you.
Common failures
Related guides
Operations overview
The operations area is the cross-resource health and runtime visibility surface for StackShift.
Agent activity API
Read safe resource-scoped agent actions, approval capabilities and recorded authorization evidence.