Production tracker scaling and launch checklist

• Pagination: Dispatch lists, movement history and report pages use keyset pagination on (time, id); page size <= 100; genealogy walks are depth-bounded and paged, never unbounded.
• Caching: Released BOMs, routings and item masters are immutable per version and cached in memory by (id, version); the floor view polls a small summary endpoint with ETag support.
• Idempotency: Operator reports use a client report id and device ingest uses (device, batch, seq) so offline replays and retries are exactly-once in effect; stock moves require an idempotency key.
• Rate limits: Per-device ingest limits and payload caps, per-site limits on report endpoints, and per-key quotas on ERP sync; a flooding device is dropped with 429 without affecting others.
• Data growth: device_readings are partitioned by day with a 30-day raw window; operation_reports, stock_moves and audit_log are partitioned by month and archived read-only, never dropped within the retention period.
• Realtime: The floor board uses short polling or SSE fed by Postgres NOTIFY per site; no dedicated websocket tier in phase 1.

• Metric ingest readings total and ingest rejects total: by device and reason; sequence gaps counted separately.
• Metric oee by work center: availability, performance, quality by shift.
• Metric open holds and ncr age: count and oldest age by severity.
• Log production audit log: request id, actor, order and lot ids, outcome; no personal data beyond ids.
• Trace operator report trace: report, balance update, notification.
• Slo genealogy completeness: 100% of produced lots have at least one consumption edge; gaps are incidents.
• Slo ingest freshness: 95% of connected devices have a reading within 2 minutes.
• Alert device silent: a device with a running order and no reading for 5 minutes alerts the supervisor.

• rollup_oee: runs cron hourly. Guard: idempotent per (work_center, shift_date, shift); reads events and reports; bounded to the last 48 h.
• prune_device_readings: runs cron daily. Guard: drop raw partitions older than 30 days only after the rollup watermark has passed them.
• escalate_overdue: runs cron every 15 minutes. Guard: late work orders, overdue CAPAs and holds without disposition are escalated once per level with SKIP LOCKED claims.
• verify_stock_balances: runs cron nightly. Guard: recompute per-lot balances from stock_moves; mismatch freezes moves for that lot and alerts.
• build_batch_record: runs queue (jobs) on lot completion or request. Guard: idempotent per lot; private bucket; signed URL.
• verify_audit_chain: runs cron nightly. Guard: incremental hash chain recompute, break is a sev-1.

• Read replicas: OEE and traceability analytics move to a read replica when primary CPU > 60% sustained or trace p95 > 2 s; operator writes stay on the primary.

Forge64 matches your description to one of 25 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

Every metered resource on Forge64 has a hard cap, so a traffic spike stops at your limit instead of becoming a surprise bill. This is a reference design for the category, not a promise that every item is generated today. Built-ins such as background jobs, file uploads and search are rolling out; email sent from your app is coming soon, so anything here that needs it is something you add yourself for now.

When should I worry about scale for a production tracker?

Not before a measured trigger fires. For example, for "OPC UA / MQTT gateway for direct machine connectivity": customer needs sub-minute machine state at more than 20 machines.

What performance targets should a production tracker aim for?

Operator report submit: p95 < 150 ms, one insert plus counter update. Floor queue load: p95 < 200 ms for 100 open operations. Recall trace (depth 8, 50k edges): p95 < 2 s.

Does Forge64 cap my usage costs?

Yes. Every metered resource has a hard cap, and paid plans add an overage spend cap that you set.

• How to build a production tracker
• Production tracker architecture
• Example prompt for a production tracker
• Production tracker security checklist
• Often combined: inventory system
• Often combined: approval workflow app
• All app types