Operations demo

SLA & Escalation Tracker

A working ticket queue that tracks every SLA — what's breached, what's about to, and the morning digest you'd send your team. Add tickets, edit them, import a CSV. Built by directing an AI assistant in plain English — one of a few small tools at nateeisenstein.com.

Sandbox. This is loaded with fictional sample data. Click any row to open and edit it, add tickets, or import a CSV — but your changes live only in this browser tab and reset when you close it. Nothing is sent anywhere or shared with other visitors.

Morning digest

A snapshot of the queue you'd send your team each morning — generated automatically.

Settings

SLA target (hours to resolve)

As of

Owner

Queue

Click a row to open it — edit the priority, owner, status, title, or dates, or mark it resolved. Changes are kept in this browser.

Status	ID	Ticket	Priority	Owner	Opened	SLA due	Age

Where the misses are

Breached / at risk / missed — by owner

By priority

Loading data

Day to day you'd add tickets right in the queue with “+ Add ticket”. Use a CSV import for the initial bulk load from Jira / Zendesk / a spreadsheet. (In a real deployment this would sync from your ticketing system automatically.) Everything stays in your browser.

Import a CSV file

Sample data — copy it to see the format

CSV/TSV with a header row. Recognised columns (any order): id, title, requester, owner, priority, opened, status, resolved, link (only title and opened are required). Dates like 2026-09-15 09:30. Priority P1–P4 or Critical / High / Medium / Low. A status of "resolved" / "closed" with a resolved date counts as done.

How I'd connect a real ticketing system This demo runs in your browser on fictional data — a deployed version would pull from Jira / Zendesk / ServiceNow and post the digest itself. Open for the approach.

Getting tickets in — a small sync service

A lightweight backend job that keeps a local copy of the queue in sync. Two mechanisms, usually both:

Scheduled pull (every 5–15 min): ask the source API for everything updated since the last run, map each ticket to the shape this tool already uses (id, title, requester, owner, priority, opened, status, resolved, link), and upsert.
Webhooks for immediacy: the source pushes an event the moment a ticket is created or changes state, so "at risk" and "breached" are never more than seconds stale.

By source

Jira / Jira Service Management — REST API v3, POST /rest/api/3/search with JQL (project = OPS AND updated >= -15m). Auth: an API token (Basic) or a 3-legged OAuth app. Webhooks via a Jira automation rule. SLA data comes straight from JSM's Time to resolution field, or you compute it from created + a priority→target map (exactly what this demo does).
Zendesk — the Incremental Exports API (/api/v2/incremental/tickets?start_time=…) is built for "give me everything changed since this timestamp". Auth: API token or OAuth. Native webhooks + triggers. Zendesk has first-class SLA policies, so you can read breach_at directly.
ServiceNow — Table API (/api/now/table/incident?sysparm_query=sys_updated_on>…), auth via Basic or OAuth. Business Rules or Flow Designer to POST outbound on change. SLA timings live in the task_sla table.
Others — Linear, GitHub Issues, PagerDuty, or a nightly CSV drop: same pattern, smaller surface.

Auth & secrets

API tokens and OAuth credentials live in the sync service's environment — never in the browser. Per-source, least-privilege: read tickets, read users. The browser only ever talks to your backend.

Sending the digest

A cron job (say 8:00 a.m. on weekdays) builds the same digest you see here and posts it itself — Slack (incoming webhook or a bot), Teams, or email — with the deep links pointing at the real tickets.

Why the demo is client-side anyway

So it's a single file with nothing to run, and anyone can try it without a login. The parsing, SLA math, and digest logic are exactly what the backend would use — only the data source changes.