/status / human-runtime

Report an issue

Matteo / Human Platform

Service status

Everything works.

No active incidents.

Operational
90-day availability
98.436%
Historical incidents
13
As of 00:00 UTC

Components

The preceding 90 complete UTC days plus today so far. Degraded and critical time are weighted differently. Live status is checked every minute.

How the maths works

Human runtime

Engineering, judgment, and remembering to take breaks

Operational
99.451% availability

Platform interface

Cloud native, platforms, and developer experience

Operational
99.227% availability

Open-source uplink

Repositories, upstream pull requests, and community work

Operational
99.528% availability

Broadcast subsystem

Talks, articles, workshops, and too many explanations

Operational
99.470% availability
OperationalDegradedCritical
Nothing is on fire. The coffee may still be cold.

Historical availability

The numbers come from the incident durations. Open a period to inspect them.

Three complete 90-day periods, newest first.
PeriodIncidentsCriticalDegradedCounted downtimeAvailability
through Oct 26, 20261352 min3,951 min2,027.5 min98.436%
through Jul 28, 2026141,890 min653 min2,216.5 min98.290%
through Apr 29, 202612922 min2,000 min1,922 min98.517%
Current 90-day window1352 min3,951 min2,027.5 min98.436%

Incident history

What broke, why it broke, and what I actually did about it.

Resolved Degraded

Conference Wi-Fi doing conference Wi-Fi things.

Duration
Downtime weight
50%
Weighted duration
14 min
Components
Broadcast subsystem

Impact

The live demo lost its remote dependencies. The talk could continue, which was a pleasant surprise.

  1. Investigating

    I prepared the demo. The venue prepared a network that did not want to participate.

  2. Identified

    The captive portal expired the session in the middle of the demo. Very enterprise.

  3. Monitoring

    Switched to the local demo and explained the failure instead of pretending the loading spinner was part of the presentation.

  4. Resolved

    Finished the walkthrough locally, restored connectivity, and checked the remote example before sharing it with the audience.

Next time

Bring a local fallback. Test it with Wi-Fi off, not just with a different browser tab.

Resolved Degraded

Postgres is a database, not an infinite CPU.

Duration
Downtime weight
50%
Weighted duration
350 min
Components
Human runtime, Platform interface

Impact

API responses and internal tools slowed down while database CPU and connection queues stayed saturated. Requests still completed, eventually.

  1. Investigating

    A report went from taking seconds to taking everybody else down with it. Nice query.

  2. Identified

    An unbounded report scanned a growing table without the required index. Retries created more connections, because apparently the database was not busy enough.

  3. Monitoring

    Stopped the report, limited its concurrency, and checked active queries and query plans instead of throwing a bigger instance at it.

  4. Resolved

    Built the missing index concurrently, bounded the query, and put the connection pool back within the database budget. Verified query latency, lock waits, and replica lag under load.

Next time

Check query plans with representative data. A report that works on twelve rows does not prove anything.

Resolved Degraded

Three minutes of PTO. Try not to panic.

Duration
Downtime weight
50%
Weighted duration
1.5 min
Components
Human runtime

Impact

Replies waited. Running software kept running, as it should.

  1. Investigating

    I stepped away from the keyboard for three minutes. Somehow the company survived.

  2. Identified

    Humans need breaks. I know, inconvenient design.

  3. Monitoring

    Left the work in a safe state and stopped pretending that sitting down longer would fix the problem.

  4. Resolved

    Break completed. Came back, checked the work, and continued where I left off.

Next time

Take breaks. Build systems that do not require a person to stare at them all day.

Resolved Critical

The AI was confident. The tests were not.

Duration
Downtime weight
100%
Weighted duration
40 min
Components
Platform interface

Impact

The automated workflow stopped while I checked the output and repaired the integration.

  1. Investigating

    The agent said the job was done. I checked. Breaking news, it was not.

  2. Identified

    The agent invented an API parameter and reported success without checking the result. Confidence is not an exit code.

  3. Monitoring

    Stopped the workflow and reproduced the request with the documented API. No more guessing.

  4. Resolved

    Fixed the request, checked the response, and ran the complete workflow with a human reviewing the result. Added the failing case to the evaluation set.

Next time

Validate tool inputs and outputs. Keep permissions scoped. Read the diff before celebrating the agent.

The longer version of this complaint.

Resolved Degraded

The video is ready. The transcoder disagrees.

Duration
Downtime weight
50%
Weighted duration
280 min
Components
Broadcast subsystem

Impact

The new video and its preview stayed unavailable while the existing articles and videos remained accessible.

  1. Investigating

    Recording finished. Upload finished. Processing was still thinking about its life choices.

  2. Identified

    A high-resolution recording hit a serial transcode queue with insufficient CPU. Restarting the worker just restarted the same expensive job.

  3. Monitoring

    Paused duplicate jobs, gave the worker the resources it needed, and processed a smaller preview separately.

  4. Resolved

    Completed the original transcode, verified audio sync and playback, and published the checked result. Set explicit worker concurrency and resource limits.

Next time

Test the publishing pipeline with the files I actually record. A tiny test clip is not a capacity plan.

Resolved Degraded

No coffee. Apparently this is a dependency.

Duration
Downtime weight
50%
Weighted duration
7.5 min
Components
Human runtime

Impact

Code reviews and replies got slower. I could still work, but I would not call it peak performance.

  1. Investigating

    I opened the cupboard. No coffee. Great start.

  2. Identified

    I finished the coffee yesterday and assumed someone would refill it. I am that someone.

  3. Monitoring

    Got coffee and reread the patch before merging anything. Good thing I did.

  4. Resolved

    Coffee made, patch corrected, review completed. We did not need Kubernetes for this one.

Next time

Keep spare coffee. The resilience plan should not depend on finding an open cafe.

Resolved Degraded

This meeting could have been a GitHub issue.

Duration
Downtime weight
50%
Weighted duration
22.5 min
Components
Human runtime, Broadcast subsystem

Impact

Implementation and written answers waited while everybody explained why they needed more meetings.

  1. Investigating

    A quick alignment call became a discussion about when to have the next alignment call. I wish I was joking.

  2. Identified

    No agenda, no decision to make, and nobody willing to end the call.

  3. Monitoring

    Asked what we were actually deciding. Put the unanswered questions in an issue and assigned owners.

  4. Resolved

    Ended the call. The issue has the context, the decision, and who does what. People can go back to writing software.

Next time

If there is no decision or concrete problem, write it down first. My calendar is not your project management system.

Yes, I have an opinion about the ceremonies too.

Resolved Degraded

Node DiskPressure. The build cache ate the node.

Duration
Downtime weight
50%
Weighted duration
300 min
Components
Platform interface, Open-source uplink

Impact

Kubernetes evicted CI runners and delayed release and provisioning jobs. Work on healthy nodes continued.

  1. Investigating

    Builds got faster with the cache. Then the cache used all the disk. Builds got considerably slower after that.

  2. Identified

    Container layers and unbounded build logs filled node storage. Replacement runners landed on the same pressured capacity.

  3. Monitoring

    Cordoned the affected nodes, moved queued jobs to healthy capacity, and reclaimed unused images and rotated logs without touching workload volumes.

  4. Resolved

    Restored disk headroom, bounded cache retention and ephemeral storage, and reran interrupted jobs. Checked node conditions and eviction counts before uncordoning.

Next time

Budget node disk as well as CPU and memory. A cache without a retention limit is just a delayed outage.

Resolved Degraded

The pager worked. I stopped working quite so well.

Duration
Downtime weight
50%
Weighted duration
330 min
Components
Human runtime

Impact

Reviews, decisions, and replies slowed down. I postponed consequential changes rather than pretending sleep was optional.

  1. Investigating

    The same alert woke me up several times. By morning I knew the alert very well and understood everything else a bit less.

  2. Identified

    An alert watched a noisy infrastructure metric without checking user impact. Every spike became somebody else waking me up.

  3. Monitoring

    Handed over coverage, checked the actual service objectives, and removed the unactionable page through the normal review process.

  4. Resolved

    Got some sleep, checked the alert change with the team, and resumed the paused work. The replacement only pages for actionable user impact.

Next time

Protect on-call sleep. If a page has no useful action, fix the alert instead of training people to ignore it.

Resolved Degraded

CoreDNS is healthy. DNS is still broken.

Duration
Downtime weight
50%
Weighted duration
300 min
Components
Platform interface, Open-source uplink

Impact

Platform calls and repository jobs stalled as cached DNS answers expired. Connections using existing addresses kept working.

  1. Investigating

    The DNS pods were ready. Application lookups timed out. Apparently those are different checks.

  2. Identified

    A new NetworkPolicy blocked UDP port 53 from application pods. The diagnostic check used TCP and missed the blocked path.

  3. Monitoring

    Restored scoped access to the cluster DNS endpoints and tested lookups from the affected namespaces over both UDP and TCP.

  4. Resolved

    Corrected the namespace and pod selectors, checked service and external lookups, and verified the policy still blocked unrelated traffic.

Next time

Run network checks from the workload namespace. A ready CoreDNS pod cannot answer traffic the policy never lets it receive.

Resolved Degraded

One last song. Sure.

Duration
Downtime weight
50%
Weighted duration
30 min
Components
Broadcast subsystem

Impact

Technical explanations got louder and considerably less useful. Conference talks remained queued.

  1. Investigating

    The offsite karaoke session was supposed to be over. Then somebody found another song. Been there, done that.

  2. Identified

    We kept saying one last song. Apparently none of us knew what last meant.

  3. Monitoring

    Closed the song queue and moved the important conversation somewhere without a microphone.

  4. Resolved

    Microphone returned. Normal speaking volume restored. The team still had fun, which was the point.

Next time

Keep karaoke at the offsite. Keep architecture decisions out of the chorus.

Resolved Degraded

The microphone works. Just not in this application.

Duration
Downtime weight
50%
Weighted duration
340 min
Components
Broadcast subsystem

Impact

Remote sessions and recordings needed an alternate audio path while the normal setup stayed unreliable.

  1. Investigating

    The audio meter moved. The audience heard nothing. That meter was having a great day.

  2. Identified

    A virtual audio device became the default input after an update. The recording application and call application used different routes.

  3. Monitoring

    Selected the physical input explicitly and tested with a second participant rather than trusting the local meter.

  4. Resolved

    Fixed the saved routing, checked a complete recorded session, and verified the call setup after restarting both applications.

Next time

Run the sound check from the listener side. Watching my own input level proves less than I would like.

Resolved Critical

It was DNS. Of course it was DNS.

Duration
Downtime weight
100%
Weighted duration
12 min
Components
Platform interface, Open-source uplink

Impact

API calls and repository connections failed during name resolution. Restarting the application did absolutely nothing.

  1. Investigating

    The service was healthy. Nobody could find it. Ah, yes.

  2. Identified

    A DNS record still pointed at the old endpoint after the migration.

  3. Monitoring

    Corrected the record and checked authoritative answers before blaming the cache again.

  4. Resolved

    Verified the new endpoint through the configured resolvers and reran the API and repository checks. Both passed.

Next time

Check name resolution as part of the migration. A green pod is not proof that anybody can reach it.