2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-29 05:05:00 +00:00
2026-04-22 05:04:19 +00:00
2026-04-29 05:05:00 +00:00
2025-12-17 20:18:50 +00:00
2026-04-26 16:31:04 +00:00
2026-04-26 16:31:04 +00:00
2025-12-17 20:24:06 +00:00
2025-12-29 18:43:39 +00:00
2026-04-22 05:04:19 +00:00
2026-04-22 05:04:19 +00:00
2026-04-24 20:47:25 +00:00
2026-04-24 20:47:25 +00:00
2026-04-29 07:13:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-24 14:45:45 +00:00
2026-04-23 17:34:21 +00:00
2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-30 16:59:42 +00:00
2026-04-22 05:04:19 +00:00
2026-04-22 05:04:19 +00:00
2026-04-26 16:31:04 +00:00
2026-04-26 16:31:04 +00:00
2025-12-17 20:24:06 +00:00
2026-04-26 16:31:04 +00:00
2026-04-29 05:05:00 +00:00
2025-12-17 20:24:06 +00:00
2026-04-29 05:05:00 +00:00
2026-04-24 14:06:15 +00:00
2026-04-24 14:06:15 +00:00
2026-04-22 05:04:19 +00:00
2026-04-22 05:04:19 +00:00
2025-12-17 20:24:06 +00:00

This is a Next.js project bootstrapped with create-next-app.

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Downtime Action Reminders

Reminders are sent by calling POST /api/downtime/actions/reminders. This endpoint does not run automatically, so you need to schedule it with cron or systemd. It sends at most one reminder per threshold (1w/1d/1h/overdue) and resets if the due date changes. The secret can be any random string; it just needs to match what your scheduler sends in the Authorization header.

  1. Set a secret in your env file (example: /etc/mis-control-tower.env):
DOWNTIME_ACTION_REMINDER_SECRET=your-secret-here
APP_BASE_URL=https://your-domain
  1. Cron example (runs hourly for 1w/1d/1h/overdue thresholds):
0 * * * * . /etc/mis-control-tower.env && curl -s -X POST "$APP_BASE_URL/api/downtime/actions/reminders?dueInDays=7" -H "Authorization: Bearer $DOWNTIME_ACTION_REMINDER_SECRET"

If you prefer systemd instead of cron, you can create a small service + timer that runs the same curl command.

Example systemd units:

/etc/systemd/system/mis-control-tower-reminders.service

[Unit]
Description=MIS Control Tower downtime action reminders

[Service]
Type=oneshot
EnvironmentFile=/etc/mis-control-tower.env
ExecStart=/usr/bin/curl -s -X POST "$APP_BASE_URL/api/downtime/actions/reminders?dueInDays=7" -H "Authorization: Bearer $DOWNTIME_ACTION_REMINDER_SECRET"

/etc/systemd/system/mis-control-tower-reminders.timer

[Unit]
Description=Run MIS Control Tower reminders hourly

[Timer]
OnCalendar=hourly
Persistent=true

[Install]
WantedBy=timers.target

Enable with:

sudo systemctl daemon-reload
sudo systemctl enable --now mis-control-tower-reminders.timer

Downtime Reason Backfill

Control-Tower now preserves manual downtime reasons from downtime-acknowledged events when later default stop events (PENDIENTE / UNCLASSIFIED) arrive for the same incident.

If historical rows were already overwritten, run the one-time backfill:

  1. Dry run (default lookback: 30 days):
npm run backfill:downtime-reasons -- --dry-run --since 30d
  1. Apply updates:
npm run backfill:downtime-reasons -- --since 30d

Optional filters:

npm run backfill:downtime-reasons -- --dry-run --since 14d --org-id <orgId> --machine-id <machineId>

Quick verification query (shows recent incidents with reason + source):

node -e 'const {PrismaClient}=require("@prisma/client");const p=new PrismaClient();(async()=>{const rows=await p.reasonEntry.findMany({where:{kind:"downtime"},orderBy:{capturedAt:"desc"},take:30,select:{id:true,orgId:true,machineId:true,episodeId:true,reasonCode:true,reasonLabel:true,capturedAt:true,meta:true}});console.log(JSON.stringify(rows,(_,v)=>typeof v==="bigint"?v.toString():v,2));})().finally(()=>p.$disconnect());'

Production build and deploy

Dev uses Turbopack, production build uses Webpack. Next.js 16 defaults to Turbopack for both, but Turbopack production builds have known issues. This project uses:

  • npm run devnext dev --turbopack (fast dev)
  • npm run buildnext build --webpack (stable production build)

When deploying (e.g. for https://mis.maliountech.com.mx):

  1. Build: Run npm run build (Webpack).
  2. Start: Run npm run start (or your process manager) to serve the built app.
  3. If you previously built with Turbopack, run rm -rf .next then npm run build for a clean Webpack build.
  4. Hard-refresh the browser (or clear site data) after redeploying so clients dont load old Turbopack chunks.

Logging and debugging

See LOGGING.md for where errors are logged (log file, process stdout, optional /api/debug/logs), how to tail them, and how to debug "Internal Server Error".

To learn more about Next.js, take a look at the following resources:

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.

Description
No description provided
Readme 2.9 MiB
Languages
TypeScript 98.3%
CSS 0.9%
JavaScript 0.8%