Triggers and Connectors: What Starts the Work
Every automation needs a starting gun and a way to reach the systems it touches. Triggers decide when a workflow runs; connectors decide what it can read and change. They are the wiring most outages actually live in.
Every automation needs a starting gun and a set of hands. Triggers decide when it runs; connectors decide what it can touch. Most outages live quietly in that wiring.
Strip any automation down and it has three parts: something that starts it, the logic in the middle, and the connections to the outside systems it reads and changes. The middle gets all the attention. The two ends — the trigger and the connectors — get almost none, and that's precisely where the trouble lives. A trigger answers when; a connector answers what it can touch — the authenticated link to each outside system, carrying the credentials that let your workflow actually read and change things there.
Triggers come in a few familiar shapes, and the first real decision is push or pull — does the outside world call you, or do you go check?
A webhook is the inbound call from the CLI course: the platform generates a URL and waits, and nothing runs until something hits it. A schedule or a poll, by contrast, runs on your clock whether or not anything happened. Push is timelier; pull is simpler and works even when the other side offers no events. Pick by whether the source can call you — and whether a few minutes' delay is fine.
Why the wiring is where outages live
Your logic, once written, rarely changes on its own. The wiring does. A connector's access token expires and every call starts failing 401 — the auth lesson from the CLI course, arriving as a 2am page. A webhook's URL changes and the trigger simply never fires, so the workflow doesn't crash — it silently stops happening, which is worse, because nothing alerts you. An outside API tweaks its format and the connector chokes. None of these are bugs in your clever middle; they're the ends coming loose, because the ends depend on a world that changes without telling you.
Where it goes wrong
Trusting a trigger you never see fail. A scheduled job that silently stops looks identical to one that has nothing to do — until you notice a week of missing results. Make the wiring loud: alert when a trigger hasn't fired in its window, when a connector returns auth errors, when a credential nears expiry. An automation that only tells you when its middle breaks is blind exactly where it's most likely to fail.
Try this
For one automation you depend on, write down its trigger and every connector it uses, and beside each note: how would I know if this broke? Any line where the honest answer is “I wouldn't, until something downstream was obviously wrong” is a blind spot in the exact place outages prefer to hide.
Grounded in the trigger/connector model common to workflow platforms such as n8n, building on the webhooks and auth lessons of the CLI · MCP · API course.