About
Reliability is a discipline.
Calm is a practice.
I'm Jeremy Martinez, a Senior Site Reliability Engineer and Incident Commander based in Las Vegas. For more than fifteen years I've designed, operated, and rescued mission-critical platforms across cloud and hybrid environments.
My work sits at the intersection of three disciplines: reliability engineering (how systems should behave when nothing is on fire), incident command (how humans should behave when everything is), and platform automation (so that neither one happens by accident).
The arc
I started in the US Army as a Communications Center Operator, working with cryptographic equipment and classified satellite systems. That foundation. Operate the equipment, trust the procedure, communicate under pressure. Shaped everything that came after.
From there I built and ran high-traffic Linux server farms, PCI-compliant hosting platforms, and streaming infrastructure for national broadcast distribution. I spent 11 years at eBay as a Production Unix Systems Engineer and senior Incident Responder. Leading triage on global e-commerce outages, holding a 99.997% uptime SLA, supporting a 10,000-node Hadoop cluster, and taking 90% of the operational toil off a 12-person team. I was recognized with a Critical Talent Bonus for that work.
At Upstart I served as Incident Commander for enterprise production incidents, coordinating engineering, operations and executive stakeholders through major outages. I owned the incident-management platform configuration end to end, built the runbooks and simulation exercises, ran the blameless postmortems, and reported reliability metrics directly to leadership every week.
Today at Dynascale I architect and operate highly available cloud platforms across AWS, Azure and GCP for multiple client production environments, serve as senior Incident Commander, lead disaster recovery strategy, and build agentic AI automation pipelines for system administration and self-healing remediation.
Why I went all-in on AI operations
Because I have watched good engineers spend their careers on work a machine should be doing. The same fifty alerts triaged by hand every morning. The same runbook re-read at 3am by someone who has read it forty times. The same postmortem action item that quietly stops being true six weeks later and is never noticed until it causes the next incident.
So I built a fleet to prove the alternative, a multi-tenant production estate run against the strictest rules I could find rather than the ones my industry happened to hand me, carrying tax records and health data, with an AI security operations centre that triages every alert, an autonomous response engine where a model may rank an option but can never name a target, network detection that can actually answer whether data left, a headless incident responder that either resolves an incident or escalates with the evidence already gathered, and every postmortem lesson re-asserted on a schedule so that it cannot quietly regress.
None of it is a demo. It runs continuously, it pages me when it breaks, and every design decision in it is written down with the reason behind it, including the ones I got wrong first.
Read how it worksWhat I actually believe
These are not stylistic preferences. Each one is a postmortem.
Assert the property, not the proxy.
A brute-force guard on one of my hosts passed its “is the service running” check for weeks while its firewall chain sat orphaned and every ban it applied was inert. Check that the thing works, never that a process exists or a package is installed.
A check that cannot fail is worse than no check.
It occupies the slot a real one would take, and it reports green forever. When I add a check, I break the system deliberately first and confirm it fires.
Verify, then claim.
Run it and paste the output. “Should work” is not a result. I have repeatedly found controls on my own fleet that were documented, believed, and not actually working, including a forced command that had been dead for six days while its client kept reporting success.
Do-no-harm beats restore-service.
A fix that could corrupt data or mask a security problem is worse than the outage. That is the first line of the brief my automated responder runs under, and it is the first thing I tell a new incident commander.
Write findings as measurements, not verdicts.
“Detection was completely inert” is a self-criticism. “This rule produced zero events across four test variants; root cause was a watch bound to a symlink inode; fixed and re-tested, four of four now detected” is a fact, and it is the one that survives being read aloud by someone hostile.
Write the standard you can meet at 3am.
Not the aspirational one. You will be held to whichever one you wrote down.
Why this site exists
I'm looking for Incident Commander and Senior/Staff SRE work, including the role where someone has to actually build the AI operations layer everyone is talking about. I also speak and run internal training on incident command, and I built Incident Commander HQ because incident command is a learnable skill and most engineering organizations are still improvising it the first time the pager goes off.