A form message that reaches nobody is worse than no form at all: the customer thinks they asked, and the business never heard. Automations make sure what happens on the website reaches a person, and that someone hears about it when the website itself has a problem.
Order and form alerts
When a customer places an order or sends a form, an alert goes to the people who need it, by email, Discord or both:
- Every field the customer filled in, under the same labels the form used, so nobody has to open another system to read it.
- Orders in full: every item, price, shipping, tax, payment status, the customer and the ship-to address.
- A link to the right place, such as the order in the staff screen or the product the customer asked about.
- No buttons the reader cannot use. A link into a dashboard only the developer can open is noise, so it is left out.
Alerts are designed like the website: the logo, clear sections, readable on a phone. A plain dump of field names is not good enough when it is the first thing a business owner reads in the morning.
Recipients that reach a human
The most common failure we see is a form that notifies a role nobody watches. When we set up a form we list its recipients by name, then send one message through the live form, written the way a customer would write it (spam filters can hold a message that reads like a test), and confirm it arrived in the inbox (including the spam and Updates tabs) and in the chat channel if one is used. Only then is the form called done.
A daily check that runs without anyone’s computer
For sites with orders, data feeds or large catalogs, a scheduled job runs every day in the cloud and checks:
- the key pages answer and load quickly, including a few random product pages and a missing page that should return “not found”;
- each data sync ran, how many items were added, changed and hidden, and whether any step logged errors;
- new and removed items, brands or categories compared with yesterday;
- yesterday’s visitors and the last seven days, and new orders and form messages.
It posts one short report: green when everything is fine, and one line per real problem with what to do about it.
No false alarms
Alerts that fire for things that do not matter teach people to ignore alerts. So the rules are strict: a problem is reported only when it is real and someone can act on it; the numbers in a report must be true (if an import failed, the report says how many items actually arrived, not how many were attempted); and when something is fixed, one short “fixed” update follows.
How it is built
Order and form events come from the platform the site runs on. A small handler on the website reads the order or message back from the platform before posting, rather than trusting the event’s contents, and only posts items that are fresh. The daily check runs as a scheduled job on GitHub’s servers. Webhook addresses, bot tokens and API keys live in secret stores, never in the code, an email or a chat.
Where it fits
Automations come with most managed hosting plans and every integration we build, because a feed nobody watches will eventually fail quietly. Member sites and custom web apps use the same alerts for new sign-ups and entries waiting for approval.
