Operating in Production
What comes after "it works on dev" — moving to production, onboarding customers, monitoring, and keeping automations healthy.
The skills that do operations work live under Building with the Plugin → Ops & Support. This page covers the higher-level concerns — what production work looks like once an integration is in customers' hands.
What you do in production
The bulk of production work is asking Claude to do these things:
- Deploy — promote a tested automation from dev to a customer's account, or push a template out to many customer accounts at once.
- Monitor — daily or weekly check-ins on customer health.
- Diagnose and repair — when something breaks, walk the failed run with Claude and converge on a fix.
- Tune alerts — suppress noise, adjust retry behavior, rewrite customer-facing alert text.
Each maps to a single ask in chat. See the relevant skill page for details.
In this section
Development System
Separate development system for teams to build and test automations without affecting production systems, with publishing workflow to production systems.
Dev to Prod
Publishing an automation from your development sandbox to production — via the plugin as the primary path, with the editor's publish workflow as a fallback.
Deploying to Customers
Distributing an automation template to customer accounts — linked deployment via the plugin, with the editor's template-admin UX as a fallback.
Monitoring
Watching production automations for errors, latency, and unusual behavior — via the plugin as the primary path.
Troubleshooting
Diagnosing why an automation failed and applying a fix — via the plugin, which searches execution history and proposes remediation.
Alerts
Controlling automation failure behavior — retry strategy, alert suppression, 401 carve-outs, and custom alert text.
Multi-Account Operations
Running APIANT for many customer accounts — account-level isolation, linked accounts for multi-location, shared credentials, and admin keyvault.