3AM free for 90 days.Claim

Paged at 2:21 a.m.Proven and fixed by 2:27

One real incident on a core banking database.

3AM's incident page: core-banking-db, DatabaseReadOnly. Proven, fixed and verified; the diagnosis

It proves the cause.It doesn't guess.

The change
read_only went from OFF to ON.

3AM compared the database with what it read before the alert. One setting had changed.

Checked twice
Every write now fails.

A second model scored the claim (supported, 90%), then live checks proved it on the primary.

The symptom
And that's the alert.

DatabaseReadOnly follows from the cause. Proven, not guessed, before anyone was asked anything.

Diagnosis
Proven
read_only on sql changed from OFF to ON
Live checks proved the root cause.
Root causeread_only on sql changed from OFF to ONProven
core-banking-db · sql
✓before the incident: OFF
✓now: ON
↓ caused
ThroughThe primary is read-only: every write failsProven
core-db-01:3306
System 1: supported 90%
✓read_only = 1 on core-db-01:3306 (expected == 1)
✓writable_primary_expected = 1 (expected == 1)
✓up = 1 on core-db-01:3306 (expected == 1)
↓ caused
SymptomDatabaseReadOnly on core-banking-dbObserved
core-banking-db
✓sql is a primary but read-only: writes fail

It shows its workEvery method, and what each found

Changes, dependencies, the alert's own questions, what changed since yesterday, error signatures. What it ruled out is on the page too.

It sees the whole incident: this alert came 25 minutes after its own fix on the app above, and it says so.

Investigation
6 methods
Pack checksdb_read_only_primary, of 2 possible causesProven
ChangesNo deploys or changes in the last 24 hNothing
DependenciesNo proven incident upstreamNothing
Evidence11 questions asked, 1 abnormalNothing
What changed3 changes near core-banking-dbLead
Error signaturesNo errors readableNothing
What it found
Driftread_only on sql changed from OFF to ON
Driftsuper_read_only on sql changed from OFF to ON
Evidencehost_status host=core-db-01 on ssh: shows failed
How this incident unfolded
2 episodes · 3 fixes by 3AM
01:55:59core-bankingFixed and verified
firstCheckerBotFailing
sql.write UPDATE schema_version SET success = 1 …01:56:49
restart_container pl-app-a-tomcat (via ssh)01:56:49
02:21:47core-banking-dbFixed and verifiedTHIS ONE
after 3AM's fixDatabaseReadOnly
set_read_write (via sql)02:26:47

A fix it has rehearsedOne tap from a person

Reversible, rehearsed with a dry run, and sent to the person on call with the evidence. 3AM applies it, then checks it worked.

Proposed fixSET GLOBAL super_read_only = OFF; SET GLOBAL read_only = OFF
Medium riskReversibleDry run passedvia sql

Make the declared primary writable again; 3AM checks writes succeed. Find out who set it read-only before it happens again.

Waiting for one approval
RejectApprove
5m 20s
from the alert to a decision
20s
from the fix to verified

Nothing happens off the recordEvery step, hash-chained

Each event carries the SHA-256 of the one before it, and every segment is sealed and signed. Change one byte and every link after it breaks.

Audit chain
Verified
5 events · this incident
alert
received · 02:21:47
········
diagnosis
proven
········
approval
granted
········
action
executed · 02:26:47
········
fix
verified · 02:27:07
········
Head

Now,howmanyplacesdoyourun?

Set it up onceEvery site has it

One install is the home. Every other site takes its connections, sign-in, people and policy, and stays in step.

WARDENSigns every licence0installDRJoining…StagingJoining…Another regionJoining…TestJoining…The homeYour first install
Warden signs one licence
In step

Change it on the home; every site follows.

End to end

Sites talk to the home directly. 3AM never sees a secret.

One key

A new site installs with one key, and joins the licence.

One licenceEvery site you run

Enterprise
10
installs, any purpose
Strategic
Unlimited
installs and instances
Every tier
All of 3AM
every feature, unlimited people

Your next incident is already scheduled.

See 3AM resolve one live in 30 minutes, then start a shadow-mode pilot that changes nothing.