Trust

Incident History

This page keeps a transparent record of operational incidents in production. Each incident includes impact, duration, root cause and actions taken.

0
Critical incidents (last 90 days)
0
Open incidents
3
Total recorded incidents
Eski kurulum betiğinin web üzerinden erişilebilir olması — yönetim veritabanında kullanılmayan tablolar Düşük Çözüldü
28.09.2026 · Affected: Administration veritabanı (kiracı verileri etkilenmedi)
  1. 2026-09-28 22:40 Oluşan tüm kalıntılar kaldırıldı; yönetim veritabanı olay öncesi haline döndü. Sağlık kontrolleri temiz. Çözüldü.
  2. 2026-09-28 22:09 Server seviyesinde ikinci koruma eklendi: kurulum/test betikleri ve bağımlılık klasörü web sunucusunda doğrudan engellendi.
  3. 2026-09-28 21:53 Etki analizi: oluşan kayıtlar yedeklendi. Müşteri/kiracı veritabanlarına erişim olmadı; oluşan yönetici kaydı hiçbir giriş akışında kullanılamıyordu (giriş yalnızca kiracı veritabanlarında doğrulanır). Hizmette kesinti yaşanmadı.
  4. 2026-09-28 20:48 Betik yalnızca sunucu komut satırından çalışacak şekilde kilitlendi; web isteklerine artık 404 döner.
  5. 2026-09-28 20:43 Planlı iç güvenlik denetimi sırasında, ilk kurulumdan kalan eski bir betiğin web sunucusu üzerinden erişilebilir olduğu tespit edildi. Denetim aracının yaptığı tek istek betiği çalıştırdı; betik yönetim veritabanında eski şemaya ait boş tablolar ve kullanılamayan bir varsayılan yönetici kaydı oluşturdu.
Postmortem

Ne oldu: Ilk kurulumda kullanılan bir betik, uygulama sunucusunun erişim kurallarından birinde engelliyken diğerinde engellenmemişti. Bu açık, dış bir saldırıyla değil, kendi planlı güvenlik denetimimiz sırasında ortaya çıktı.

Etki: Müşteri verisine erişim, veri kaybı veya kesinti yok. Server erişim kayıtları (14–28 September) betiğe gelen tüm isteklerin denetimimize ait olduğunu, tabloların oluşturulma zamanı da betiğin bu olaydan önce çalıştırıldığına dair iz bulunmadığını gösteriyor.

Önlemler:

  • Tüm kurulum/test betikleri artık yalnızca komut satırından çalışır (kod seviyesinde kilit).
  • Web sunucusu erişim kuralları iki katmanda birebir eşitlendi; yeni betik eklendiğinde her iki listeye de eklenmesi süreç kuralı oldu.
  • Otomatik denetim araçlarının canlı ortamda bu tür betiklere hiçbir koşulda istek atmaması kural olarak eklendi.
Super admin paneli 502 Bad Gateway — PDOStatement cast warning loop Yüksek Çözüldü
22.06.2026 · Affected: Süper admin paneli (giriş sonrası dashboard)
  1. 2026-06-22 13:37 MigrationRunner DDL-unsafe çıktı: ilk migrate.php çağrısı "There is no active transaction" verdi. MySQL'de CREATE/ALTER TABLE implicit commit yapar. inTransaction() guard up() ve rollback() içine eklendi.
  2. 2026-06-22 13:35 Ikincil noise tespit edildi: td_master.audit_log tablosu yoktu, SA login event'i audit'e yazılamıyor SQLSTATE 42S02 üretiyordu. Master DB'de tablo oluşturuldu, init_master.php + versioned migration 20260622_000001 eklendi.
  3. 2026-06-22 13:31 Hotfix deploy: ölü kod kaldırıldı, hemen altındaki $cntSt = $tdb->prepare(...); $cntSt->execute(); $cnt = (int)$cntSt->fetchColumn(); doğru kullanımı kaldı.
  4. 2026-06-22 13:30 Root cause tespit edildi: super_admin/index.php:41-44'te ölü kod ($cnt = (int)$tdb->prepare(...)) PDOStatement'i int'e cast etmeye çalışıyordu. Bu yalnızca warning, ama 22 aktif tenant'a karşı for-loop'ta tetiklenince Logger her seferinde tek satır JSON'u FastCGI stderr'e basıyordu. nginx tarafında upstream sent too big header → 502.
  5. 2026-06-22 09:48 Ilk hata raporu: kullanıcı SA login sonrası /super_admin/index.php'te 502 Bad Gateway alıyor.
Postmortem
Tetikleyici: Geçen sprintlerde super_admin/index.php'e online users mantığı eklenirken eski 4 satırlık deneme blok silinmemiş, ölü kod kalmıştı. Tek başına PHP warning, ama Logger sayesinde her warning artık stderr'e structured log basıyor; aktif tenant sayısı arttıkça (22+) header buffer'a sığmaz oldu. Önlemler: (1) ölü kod kaldırıldı, (2) Logger'ın FastCGI stderr basma davranışı yeniden değerlendirilecek — same-message dedup (rate-limit per-request) bir sonraki sprintte eklenebilir, (3) MigrationRunner DDL-safe oldu — gelecekteki tüm CREATE/ALTER TABLE migration'ları "transaction yok" exception'ı yaşamayacak, (4) master DB'de artık audit_log tablosu var, SA işlemleri (login, tenant create/delete, ai_kb edit) cross-tenant audit_search'te görünecek.
Günlük backup script silent failure (geriye dönük tespit) Yüksek Çözüldü
21.06.2026 · Affected: Günlük yedek, DR güveni
  1. 2026-06-22 02:26 Haftalık integrity check cron kuruldu (Pazar 04:00). Ilk run: 8 dosya SHA256 OK, 7 sql.gz gunzip OK.
  2. 2026-06-22 00:04 Yeni multi-tenant aware backup script (v2) yazıldı, deploy edildi. Manuel run: master + 6 tenant + app files = 52MB başarılı.
  3. 2026-06-21 23:00 Logger pipeline kurulduktan sonra yapılan integrity audit'te tespit: 2 ay+ boyunca $DB_NAME env tanımsızlığı yüzünden 388 byte'lık boş dump üretiliyordu.
  4. 2026-04-28 Eski backup script son başarılı çalışmasını gerçekleştirdi (geriye dönük tespit edildi).
Postmortem
Tetikleyici: Yeni sistem secret'larından gelen $DB_NAME bağımlılığı; eski script config.php yerine bekliyordu. Tespit gecikmesinin sebebi: backup tar.gz boyutu kontrol edilmiyordu (bir dosya vardı, başarı sayıldı). Önlem: yeni script min 1KB sanity check + last_run.json meta + /health.php component + haftalık integrity check.

What is recorded here?

A chronological list: date, affected component, severity, timeline and the postmortem published after resolution (root cause and preventive actions). Incidents that did not affect service but that we share for transparency are also listed. For live status see status.php.

To stay informed

Critical incidents are announced by email to active customers. RSS/Atom feed support is on our roadmap.