If the automation breaks, who fixes it and how fast?

If it breaks, it gets fixed by whoever is named in the contract, within the timeframe that contract sets: for a critical flow, detection in under 15 minutes and restoration within the same business day. If there is no name and no deadline in writing, the real answer is that nobody fixes it until a customer complains, and that takes days. Every automation that depends on a third-party API —WhatsApp, Mercado Libre, Google Calendar, an AI provider— breaks at some point, and almost never because of a bug in the code: it breaks because something changed outside. What separates a 40-minute incident from a three-day one is not the quality of the development, it is three decisions made before signing: who receives the alert, how fast the failure is detected and what the committed restoration deadline is. If your contract does not say those three things, you do not have support: you have a phone number.

Almost nothing breaks on its own: something changes outside and your flow is the last to find out

These are the failure modes that show up in real operations, with first and last name:

• The API version you were using gets shut down. Meta versions the Graph API and each version has a life span of around two years; the shutdown date is published months in advance in the developer changelog. When the day arrives, calls to that version stop responding. It is the most predictable failure there is and also one of the most common, because the notice goes to whoever administers the Meta app, not to the business owner.
• A token expires that nobody knew had an expiry date. The classic: someone generated the 24-hour temporary token in the Meta panel to run a test, and that token stayed glued into production. The slow variant is worse: the system user token does not expire on a timer, but it is tied to an account. If that account loses access to Business Manager, the token dies with it.
• The person who authorized the accounts leaves. The administrative assistant connected Google Calendar and the email inbox with her own user. She resigns, her corporate account is deactivated on Friday, and on Monday the bot cannot read the calendar or send confirmations. Nobody connects one thing with the other for days, because the offboarding ticket does not say that this user was holding up three integrations.
• The AI model is retired. The model name is written into the node. On shutdown day, every message returns a model-not-found error. Providers give months of notice, but the notice arrives by email to the account that created the API key, which in many cases belongs to the vendor and not to you. If that relationship has cooled off, the notice is read by an inbox nobody opens.
• The HTML of a system with no API changes. A wholesaler's portal, a health insurer's panel, an insurance company's extranet: when there is no API, the flow reads the screen. A redesign, a field that starts loading via JavaScript or a new captcha, and the data can no longer be found. There is no advance notice and nobody to complain to. If part of your operation depends on reading someone else's screens, assume at least one break per year and budget for it.
• Your own volume changes. Nobody touched anything, but you went from 400 to 1,400 conversations per month and the API starts returning 429 (too many requests) at the 11:00 peak. It is the hardest failure to diagnose because it is intermittent: at 16:00 it works perfectly and the customer's complaint sounds like an exaggeration.

We monitor 24/7 means nothing: ask for these four pieces

Real monitoring is four concrete, verifiable things. If any one of them is missing, there is a failure mode from the list above that nobody will see until a customer sees it.

An alert that fires on absence, not only on error. If the reminder flow sends 40 messages every morning at 9, the useful alert is not "the node failed", it is "by 9:15 no send was recorded". It is implemented with a heartbeat-type monitor: the flow reports that it ran and an external service (healthchecks.io, Better Stack, or a separate watchdog flow) shouts if that report does not arrive. Without this, the execution that ends green without having done anything is detected by nobody, and that is the failure that costs the most.

Retries with increasing wait times, and only for the errors that warrant it. A 429 or a 503 is temporary: retrying after 5 seconds, after 25 and after a minute resolves most of them without anyone noticing. A 401 (invalid credential) or a 400 (malformed data) are not fixed by retrying; there the retry only multiplies the error and on some platforms speeds up the block. In n8n these are two options per node, Retry On Fail and Wait Between Tries, plus a branch that separates the error type. Ask whether they are configured: in n8n they come switched off by default, so if nobody touched them node by node, they are not.

Idempotency, so that retrying does not duplicate. It is the piece that gets skipped the most and the one that generates the most awkward incidents with customers. If the retry runs the whole action again, the same person gets two WhatsApp messages, the same invoice is issued twice or the stock is deducted twice. The solution is cheap: before running, store the source identifier of the event —the message id, the order number, the appointment id— in a table with a uniqueness constraint, and if it already exists, do not run. The question for your vendor is literal: if the same webhook arrives twice, and it does arrive, because platforms resend when they do not get a response in time, what happens?

An error queue that someone looks at. Whatever failed after all the retries cannot die in a log. It goes to a table, a spreadsheet or a channel, with enough data to reprocess it once the cause is fixed; n8n has Error Workflow for exactly that. The practical difference: when the token is reauthorized on Tuesday, Monday's 63 messages are resent in two minutes instead of being lost forever.

The same incident, with and without those pieces

Scenario: an e-commerce business with 900 SKUs selling on Tiendanube and Mercado Libre —the dominant online store platform and marketplace in Latin America— with an n8n flow that synchronizes stock every 10 minutes. On a Friday at 19:40 the Mercado Libre credential is invalidated. Average order value USD 62. The figures are typical for a small e-commerce business in the region, not audited results from a specific company.

Without monitoring. The synchronization stops running and the Mercado Libre listings keep showing Friday afternoon's stock. It is detected on Monday at 9:30, when the third complaint comes in: 62 hours of failure. In the meantime 11 units were sold that no longer existed, which have to be cancelled from the seller account. Direct cost: USD 682 in lost sales, plus around 3 hours of the customer service person's time handling cancellations and refunds, plus the hit to the seller reputation, which is calculated on recent sales and takes months to recover. The technical fix is 40 minutes of reauthorization. The fix is never the expensive part.

With the four pieces. Two consecutive failed cycles (20 minutes) trigger the alert. The flow goes into safe mode: instead of leaving published a stock level it can no longer validate, it freezes the listings or takes them to zero. At 20:15 someone reauthorizes from their phone; if there is no on-call coverage, it is reauthorized on Monday at 9 and in the meantime nothing was sold that did not exist. The error queue reprocesses the pending stock changes. Cost: 40 minutes of work and a few sales not made, which are much cheaper than cancelled sales.

The design decision that saves the most money is the one that almost never gets quoted: defining what the system does when it cannot comply. A bot that fails to look up a price has to say "let me put you through to a person", not invent a number or go silent.

The six questions that separate real support from a phone number

1. What alert fires, who does it reach and how fast? A good answer sounds like this: if by 9:15 the batch has not gone out, a notice comes into the support channel and, if after 30 minutes it is still unresolved, an email to you.
2. What is the response time and what is the restoration time? They are different things and it is worth asking for them by severity: bot down, partial failure, cosmetic detail. An acknowledgment within 4 business hours is not a solution within 4 business hours.
3. What happens on a Saturday at 22? The honest and acceptable answer is "there is no on-call coverage, it is handled on Monday at 9, unless you contract on-call separately". The suspicious answer is "there is always someone".
4. Are third-party changes included in the retainer or quoted separately? When Meta shuts down the API version or the provider retires the model, who pays for that migration? It is the clause that moves the most money and the one almost nobody asks about.
5. Who else, besides the person who built it, can get in tomorrow? If the answer is a personal name, your automation has a single point of failure and it is human. What solves it is documentation and credentials in a shared manager, not trust.
6. What is the manual plan while it is down? The number keeps receiving messages. Having someone able to reply by hand from the shared inbox —Chatwoot or whichever you use— turns a loss into an annoyance.

Disqualifying answers: "that does not break", "it is in the cloud", and any SLA that talks only about server uptime. The VPS being at 99.9% says nothing about whether your messages went out: the server can be spotless with a token that expired a week ago.

The fire drill: ask them to break the flow in front of you, in month 1

The fire drill takes 20 minutes. A credential is deliberately revoked in a test environment, or the sending node is switched off, and three things are timed: how long the alert takes to arrive, who it reaches and whether the failed events were left somewhere for reprocessing. If after 30 minutes nothing arrived, the monitoring does not exist, whatever the contract says. It is the same gesture as pressing the test button on a smoke detector: the device hanging from the ceiling proves nothing, the beep does. Asking for it in month 1 is free; discovering it in month 8 costs the whole incident.

When this is not worth the money

Not every flow needs paid monitoring, and selling it anyway would mean charging you for noise:

• If the flow is internal and can tolerate a day. Consolidating the monthly sales report in Looker Studio: if it fails on the 1st, it runs on the 2nd and nothing happened. Alerting on that trains the team to ignore alerts, which is worse than not having them.
• If it runs twice a year. A year-end close or a seasonal upload is better covered by a review before each run than by 12 months of monitoring.
• If nobody outside finds out before you do. That is the practical rule: monitor whatever, if it fails, is noticed first by a customer, a patient or a buyer.
• If you already have an IT team with on-call coverage. Paying for a second on-call rota is paying twice. What is worth buying is knowledge of the stack and documentation, not availability.

What we look at first when someone calls us with an already-broken flow

First, which credentials are still alive and in whose name: a token tied to someone who no longer works there is fixed differently from an expired one. Then, which version of each API is written into the flow and whether that version already has a published shutdown date. With those two answers you know whether what you have is a 40-minute problem or a rebuild.

That review is the free 15-minute audit, and in several cases it ends with a "this does not need monitoring: reauthorize the token, document who owns each account and carry on". If you want to run it on your own case, write to us at info@striqtech.com or book a slot from striqtech.com.