EverShop is an open-source Node.js eCommerce platform that combines server-side rendered React storefronts with a GraphQL API and a built-in admin panel — all in a single Node.js/Express process backed by MySQL. Because the storefront rendering, GraphQL API, and admin panel all share one process, a single bad deployment, a memory leak, or a MySQL connection failure can take everything offline simultaneously. Vigilmon gives you continuous coverage of every layer: application health, MySQL, storefront performance, admin panel, order success rate, and Node.js runtime health.
What You'll Set Up
- HTTP uptime monitor for the EverShop storefront
- HTTP uptime monitor for the EverShop admin panel
- MySQL connectivity heartbeat
- Storefront page response time alert (p95 > 2 s)
- Order success rate heartbeat
- Product catalog response time monitor
- Media storage disk-usage heartbeat
- Node.js process health (memory and event loop lag)
Prerequisites
- EverShop running on your server (default port 3000), accessible via HTTP or HTTPS
- A free Vigilmon account
Step 1: Monitor the EverShop Storefront
EverShop's Node.js server renders storefront pages server-side. If the process crashes or enters an error state, every page returns 500 — customers see a broken store.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter your EverShop storefront URL:
http://your-server-ip:3000. - Set Expected HTTP status to
200. - Enable Response body must contain and enter a store-specific string such as your shop name or
</html>. - Set Check interval to
1 minute. - Click Save.
If EverShop is behind a reverse proxy:
https://yourstore.com
The body assertion confirms that the Node.js SSR pipeline is fully rendering pages — a 200 with an empty body would indicate a partial startup failure without this check.
Step 2: Monitor the EverShop Admin Panel
EverShop's admin panel is served by the same Node.js process as the storefront, but its failure mode is often different: authentication middleware errors or route failures can break /admin while the storefront remains up.
- In Vigilmon, click Add Monitor → HTTP / HTTPS.
- Enter:
http://your-server-ip:3000/admin. - Set Expected HTTP status to
200. - Enable Response body must contain and enter
</html>. - Set Check interval to
2 minutes. - Click Save.
If your admin uses a custom path (e.g. /manage), update the URL accordingly.
Step 3: Monitor MySQL Connectivity
MySQL is EverShop's exclusive data store for products, orders, customers, inventory, and promotions. A database connection failure makes every storefront page that queries data fail.
- In Vigilmon, click Add Monitor → Cron Heartbeat.
- Set the expected interval to
5 minutes. - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/evershop-db-check.sh
DB_HOST="localhost"
DB_PORT="3306"
DB_NAME="evershop"
DB_USER="evershop"
DB_PASS="your-password"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-db-heartbeat"
RESULT=$(mysql -h "$DB_HOST" -P "$DB_PORT" -u "$DB_USER" -p"$DB_PASS" \
-e "SELECT 1;" "$DB_NAME" 2>/dev/null | tail -1)
if [ "$RESULT" = "1" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "ERROR: MySQL connectivity check failed"
fi
Make executable and schedule every 5 minutes:
chmod +x /usr/local/bin/evershop-db-check.sh
crontab -e
# Add:
*/5 * * * * /usr/local/bin/evershop-db-check.sh
Set the heartbeat Grace period to 6 minutes.
Step 4: Monitor Storefront Page Response Time
EverShop's SSR React pages must render and deliver HTML quickly. A product detail page that takes more than 2 seconds degrades conversion rates directly.
- Open the storefront monitor created in Step 1.
- Enable Alert if response time exceeds and set it to
2000 ms. - Click Save.
For deeper per-page latency tracking on critical pages, create dedicated monitors:
Homepage:
- Click Add Monitor → HTTP / HTTPS.
- Enter:
http://your-server-ip:3000. - Enable Alert if response time exceeds:
2000 ms. - Set Check interval to
2 minutes.
Product listing page (PLP):
- Click Add Monitor → HTTP / HTTPS.
- Enter a real category URL:
http://your-server-ip:3000/your-category. - Enable Alert if response time exceeds:
2000 ms. - Set Check interval to
5 minutes.
Step 5: Monitor Order Success Rate
A checkout failure is the most expensive failure in an eCommerce platform. Add a heartbeat that verifies EverShop's GraphQL order endpoint is responding correctly:
- In Vigilmon, create a Cron Heartbeat with a
15 minuteexpected interval. - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/evershop-order-check.sh
GRAPHQL_URL="http://localhost:3000/api/graphql"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-order-heartbeat"
# Lightweight introspection check on the GraphQL endpoint (not a real order)
QUERY='{"query":"{ __typename }"}'
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -m 10 \
-X POST "$GRAPHQL_URL" \
-H "Content-Type: application/json" \
-d "$QUERY")
if [ "$HTTP_CODE" = "200" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: GraphQL API returned HTTP $HTTP_CODE"
fi
Schedule every 15 minutes:
*/15 * * * * /usr/local/bin/evershop-order-check.sh
For deeper order validation in a staging environment, use a test order script that exercises the full checkout GraphQL mutation. In production, monitor order creation success rates via your EverShop logs:
# Count order creation errors in the last 5 minutes
grep "$(date -d '5 minutes ago' +'%Y-%m-%dT%H:%M')" /var/log/evershop/app.log \
| grep -c "order.create.*error"
Alert if this count exceeds 2% of total order creation attempts.
Step 6: Monitor Product Catalog Response Time
The product listing page and GraphQL catalog queries are the most-trafficked parts of any EverShop store. Slow catalog responses mean customers leave before adding anything to cart.
- In Vigilmon, click Add Monitor → HTTP / HTTPS.
- Enter the EverShop GraphQL endpoint with a product search query.
- Set Method to
POST, headerContent-Type: application/json, and body:
{"query": "{ products(filters: [], page: 1, pageSize: 10) { items { uuid name } } }"}
- Set Expected HTTP status to
200. - Enable Alert if response time exceeds:
1500 ms. - Set Check interval to
5 minutes. - Click Save.
Step 7: Monitor Media Storage
EverShop stores product images and uploaded files on the local filesystem. If the disk fills up, new product image uploads fail silently and the admin panel shows broken images.
- In Vigilmon, create a Cron Heartbeat with a
30 minuteexpected interval. - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/evershop-media-check.sh
MEDIA_DIR="/path/to/evershop/media"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-media-heartbeat"
DISK_THRESHOLD=80 # percent
USAGE=$(df "$MEDIA_DIR" | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -lt "$DISK_THRESHOLD" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: Media disk usage ${USAGE}% (threshold ${DISK_THRESHOLD}%)"
fi
Schedule every 30 minutes:
*/30 * * * * /usr/local/bin/evershop-media-check.sh
Step 8: Monitor Node.js Process Health
EverShop's single Node.js process handles SSR rendering, GraphQL queries, and admin operations concurrently. High memory usage or event loop lag causes progressive degradation — response times rise before the process crashes outright.
Add a heartbeat that checks Node.js process metrics:
#!/bin/bash
# /usr/local/bin/evershop-node-health.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-node-heartbeat"
MAX_RSS_MB=1024 # Alert if RSS memory exceeds 1 GB
PID_FILE="/var/run/evershop.pid"
if [ ! -f "$PID_FILE" ]; then
echo "ERROR: EverShop PID file not found"
exit 1
fi
PID=$(cat "$PID_FILE")
# Get RSS memory in MB
RSS_KB=$(cat /proc/"$PID"/status 2>/dev/null | grep VmRSS | awk '{print $2}')
RSS_MB=$(( RSS_KB / 1024 ))
if [ "$RSS_MB" -lt "$MAX_RSS_MB" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: EverShop memory ${RSS_MB}MB (limit ${MAX_RSS_MB}MB)"
fi
Schedule every 5 minutes:
*/5 * * * * /usr/local/bin/evershop-node-health.sh
For event loop lag monitoring, add the clinic or @pm2/io metrics packages to your EverShop deployment and expose them via a /health endpoint.
Step 9: Configure Alert Channels
- Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
- Set Consecutive failures before alert to
2on the storefront and admin monitors — a brief Node.js restart during deployment takes several seconds. - Set Consecutive failures before alert to
1on the MySQL monitor — any database interruption immediately breaks all data-dependent pages.
Route monitors to urgency channels:
- Storefront down, MySQL failure → Slack #store-critical (immediate, wake on-call)
- Admin panel down, checkout GraphQL error → Slack #store-ops (urgent within 15 minutes)
- Disk usage, memory alerts → email (investigate at next shift)
Summary
| Monitor | Target | What It Catches |
|---|---|---|
| Storefront | GET / + body assertion | Node.js SSR process crash |
| Admin panel | GET /admin | Admin route failure |
| MySQL heartbeat | SELECT 1 every 5 min | Database connectivity loss |
| Storefront p95 | Alert > 2 s | SSR rendering slowdown |
| GraphQL order API | POST /api/graphql + __typename | Checkout pipeline failure |
| Catalog query | Products GraphQL p95 > 1.5 s | Catalog browsing degraded |
| Media disk | df every 30 min | Product image uploads failing |
| Node.js memory | RSS every 5 min | Memory leak heading for OOM crash |
EverShop's integrated architecture means one process serves everything — speed and simplicity come at the cost of a single failure domain. Vigilmon gives you early warning at every layer so a memory leak or MySQL hiccup gets addressed before it becomes a downed store.