POWER AUTOMATE’TE HATA İZLEME: LOG, UYARI VE SÜREÇ DAYANIKLILIĞI

Otomasyonlarınız “çalışıyor gibi” görünebilir; ta ki bir gün kritik bir onay akışı takılı kalıp kimse fark etmeyene kadar. Power Automate, hızlı değer üretmek için harika bir platformdur; ancak kurumsal ölçekte en büyük farkı hata görünürlüğü, doğru uyarı stratejisi ve tasarımsal dayanıklılık yaratır. Bu üçü olmadan, küçük bir entegrasyon aksaması bile zincirleme etkilerle operasyonu durdurabilir.

Bu makalede, Power Automate akışlarınızda hataları “yakalamak” yerine, hatayı anlaşılır ve aksiyona dönüşür hâle getiren yaklaşımı ele alacağız. Run geçmişi, log tasarımı, uyarı kanalları, tekrar deneme ve telafi adımları, idempotency ve SLA odaklı izleme gibi başlıklarla; hem geliştiricilerin hem de karar vericilerin ortak dili olan ölçülebilir operasyonel güvenilirliği hedefleyeceğiz.

Özellikle çok adımlı entegrasyon akışları, yoğun e-posta/Teams bildirimleri, SharePoint/Dataverse güncellemeleri ve üçüncü taraf API çağrıları içeren senaryolarda; doğru “hata izleme” kurgusu, sadece hatayı görmek değil, hatayı önlemek ve etkisini sınırlamak anlamına gelir.

Primary yaklaşım: Power Automate hata izleme nedir ve neden kritik?

Power Automate hata izleme, bir akışın (flow) çalıştırmaları boyunca oluşan başarısızlıkların, gecikmelerin, tekrar denemelerin ve veri tutarsızlıklarının görünür hâle getirilmesidir. Basit bir “başarısız oldu” bilgisi, çoğu zaman operasyon için yetersizdir. Kurumsal ihtiyaç, “ne oldu, nerede oldu, hangi veriyi etkiledi, kaç kayıt etkilendi, otomatik toparlandı mı, manuel aksiyon gerekli mi?” sorularına net cevap vermektir.

Hata izleme, iki farklı katmanda ele alınmalıdır: (1) Akış içi gözlemlenebilirlik: adım adım iz bırakma, korelasyon kimliği, iş kuralı sonucu, hata türü gibi bilgilerin toplanması; (2) Akış dışı operasyon: uyarılar, dashboard’lar, trend analizi ve SLO/SLA takibi. Bu yaklaşım, sadece IT’nin değil, süreç sahiplerinin de karar almasını kolaylaştırır.

Run geçmişini doğru okumak: “Flow run history analizi” için pratik kontrol listesi

Power Automate’in run geçmişi (run history), ilk başvurulacak yerdir; fakat tek başına yeterli değildir. Yine de doğru okuma alışkanlığı, sorunların %60–70’ini hızlıca izole eder. Run geçmişini incelerken, yalnızca kırmızı bir adımı bulmak yerine bağlam arayın: tetikleyici girdisi, veri boyutu, yanıt kodu, concurrency etkisi, bağlantı (connector) limitleri ve “Configure run after” davranışı.

1) Hata türünü sınıflandırın: geçici mi, kalıcı mı?

Hata izleme kurgusu için ilk adım, hatayı sınıflandırmaktır. Örneğin 429 (throttling) veya 503 (service unavailable) genellikle geçicidir; tekrar deneme ile toparlanabilir. 400 (bad request), veri şeması bozukluğu veya yetki eksikliği gibi durumlar çoğunlukla kalıcıdır ve veri/konfigürasyon düzeltmesi gerektirir. Sınıflandırma, uyarı seviyesini ve otomatik telafi adımlarını belirler.

2) “Giriş verisi” ve “etkilenen kayıt” bilgisini loglayın

Bir run’ın başarısız olması tek başına anlamlı değildir; hangi iş öğesini etkilediği önemlidir. Örneğin “InvoiceId”, “CaseNumber”, “RequestId” gibi alanları loglamazsanız, hatayı iş tarafı ile eşleştirmek zorlaşır. Bu nedenle, tetikleyici sonrası erken aşamada bir korelasyon kimliği üretip (veya gelen kimliği kullanıp) her kritik adımda taşımak iyi bir pratiktir.

3) Süre ve gecikme metriklerini takip edin

Akışınız başarısız olmadan önce yavaşlıyor olabilir. Özellikle onay akışları, insan etkileşimi veya dış servis çağrıları, toplam süreyi uzatabilir. “Yavaş ama başarılı” koşulları, çoğu zaman SLA ihlaline yol açar. Bu yüzden sadece hata değil, performans anomalisi de izlenmelidir.

Akış içi loglama tasarımı: minimum ama yeterli kayıt seti

Loglama, “her şeyi yazalım” yaklaşımı değildir; maliyeti ve gürültüsü artar. Ama “hiç yazmayalım” da değildir; bu kez kör kalırsınız. Dengeli bir log tasarımı için, her run’da toplanması önerilen minimum alanları belirleyin: korelasyon kimliği, akış adı/sürümü, tetikleyici türü, iş nesnesi anahtarı, adım adı, sonuç (Success/Fail), hata kodu, hata mesajı özeti, süre, yeniden deneme sayısı ve gerekirse “tenant/environment” bilgisi.

Log seviyeleri: Info, Warning, Error

Kurumsal senaryolarda log seviyeleri, uyarı kanallarını yönetmeyi kolaylaştırır. “Info” seviyesinde sadece temel akış izi; “Warning” seviyesinde toparlanan sorunlar (ör. geçici hatalar, otomatik retry sonrası başarı); “Error” seviyesinde manuel müdahale gerektiren kalıcı hatalar tutulabilir. Böylece uyarı spam’i azalır ve operasyon ekibi gerçek riske odaklanır.

Log hedefi seçimi: Dataverse, SharePoint liste, Azure Log Analytics

Logları nereye yazacağınız, kurumsal olgunlukla doğrudan ilişkilidir. Dataverse, şema kontrollü ve raporlamaya uygun bir seçenek sunar. SharePoint listeleri hızlıdır ama büyüdükçe yönetim zorlaşabilir. Azure Log Analytics (veya Application Insights entegrasyonları), arama ve korelasyon kabiliyeti güçlü olduğu için ileri seviye gözlemlenebilirlik sağlar. Hedef ne olursa olsun, log kaydı için ayrı bir “Log Action” kalıbı oluşturup yeniden kullanılabilir hâle getirmek, standardizasyonu artırır.

Try/Catch benzeri kurgu: Scope + Configure run after ile kontrollü hata yakalama

Power Automate’te klasik programlama dillerindeki try/catch yapısı doğrudan yoktur; fakat Scope + Configure run after kombinasyonu ile aynı etkiyi elde edebilirsiniz. En iyi pratik, kritik adımları “Try” scope’una almak; başarısızlık/timeout durumunda “Catch” scope’unu tetiklemek; her koşulda “Finally” scope’unda log/temizlik adımlarını çalıştırmaktır.

// Örnek yapı (mantıksal akış şeması)
// Scope: TRY
//   - HTTP: Üçüncü taraf API çağrısı
//   - Parse JSON: Yanıt doğrulama
//   - Update row: Dataverse güncelleme
//
// Scope: CATCH (Configure run after: has failed, has timed out)
//   - Compose: ErrorSummary (statusCode, message, step)
//   - Create row: FlowLogs (Level=Error, CorrelationId, BusinessKey, ErrorSummary)
//   - Post message: Teams/Email uyarısı (kritikse)
//
// Scope: FINALLY (Configure run after: succeeded, failed, skipped, timed out)
//   - Create row: FlowLogs (Level=Info, Duration, RetryCount, Outcome)
//   - Terminate: Success/Failed (standart kapanış)

Catch içinde “hata bağlamını” zenginleştirin

Catch scope’u yalnızca “hata oldu” dememeli; hatanın bağlamını zenginleştirmelidir. Örneğin API yanıtı varsa (kısmi), hangi endpoint çağrıldı, hangi kullanıcı/servis hesabı kullanıldı, hangi payload alanı sorunlu, hangi iş nesnesi etkileniyor gibi bilgiler uyarının kalitesini artırır. Burada amaç, ekiplerin run ekranında dakikalar kaybetmeden doğrudan aksiyon almasıdır.

Finally ile standart kapanış ve ölçüm

Finally scope’u, her run’ın sonunda aynı formatta ölçüm üretmenizi sağlar. “Outcome”, “DurationMs”, “StepsCompleted”, “RetriesUsed” gibi alanlar; trend analizi ve kapasite planlama için değerli veri noktalarıdır. Ayrıca Finally içinde “cleanup” işleri (geçici kayıt silme, kilit kaldırma) planlanabilir.

Retry policy ve dayanıklılık: geçici hataları otomatik toparlamak

Dayanıklılık, yalnızca “retry açtım” demek değildir. Doğru tekrar deneme stratejisi; hata türünü tanımayı, bekleme sürelerini (backoff), maksimum deneme sayısını ve idempotency tasarımını içerir. Bazı connector’lar otomatik retry uygular; fakat her durumda yeterli değildir. Kritik aksiyonlarda retry davranışını bilinçli yönetmek gerekir.

Backoff stratejisi: sabit bekleme yerine artan bekleme

Throttling veya geçici servis problemlerinde sabit aralıkla denemek, sorunu büyütebilir. Artan bekleme (ör. 10s, 30s, 90s) yaklaşımı, sistemin kendini toparlamasına fırsat verir. Ayrıca çoklu akışların aynı anda retry yapması, dalga etkisi yaratabilir; concurrency ve batch tasarımını da göz önünde bulundurun.

Idempotency: aynı isteği iki kez çalıştırınca ne olur?

Retry, aynı işlemin tekrar çalışması demektir. Eğer işlem “fatura oluştur” gibi yan etkili bir aksiyonsa, iki kez çalıştırılması çifte kayıt üretebilir. Bu yüzden idempotency önemlidir: aynı “BusinessKey” ile ikinci kez gelen isteği ya engelleyin ya da güvenli bir “upsert” yaklaşımı kullanın. Bu tasarım, hem veri kalitesini korur hem de otomatik toparlanmayı mümkün kılar.

Uyarı (alerting) tasarımı: doğru kişiye, doğru şiddette, doğru kanaldan

Uyarı yönetimi, hata izleme başarısının görünür yüzüdür. Kural basittir: Uyarı alan kişi, uyarıyı kapatabilecek yetkiye veya aksiyon kanalına sahip olmalıdır. Aksi hâlde uyarılar zamanla “gürültü” olur ve gerçek krizler kaçırılır. Kurumsal yapılarda uyarılar genelde üç seviyede tasarlanır: Operasyon (anlık çözüm), ürün/süreç sahibi (etki analizi), teknik ekip (kök neden).

Şiddet seviyesi (severity) ve eşik kurgusu

Tüm hatalar aynı değildir. Örneğin tek bir kayıt hatası “Warning” olabilir; ancak aynı hata 10 dakika içinde 50 kez olduysa artık “Major” seviyesine çıkar. Bu yüzden eşik (threshold) mantığı kritiktir: belirli bir süre penceresinde hata sayısı, başarısızlık oranı, ortalama süre artışı gibi metriklerle uyarı üretmek, gereksiz bildirimleri azaltır.

Teams, e-posta ve ITSM: kanal seçimini operasyon modeli belirler

Teams bildirimleri hızlı geri dönüş sağlar; e-posta daha kalıcıdır ama gecikmeli okunabilir. ITSM (ör. ServiceNow/Jira) entegrasyonu, kurumsal iz kayıtları ve SLA takibi için idealdir. Uyarı kanalını seçerken, olay yönetimi sürecinizin olgunluğunu temel alın. Birçok kurum için “kritik hatada Teams + ticket”, “uyarı seviyesinde günlük özet e-posta” dengeli bir başlangıçtır.

Power Automate kullanımınızı derinleştirmek, standart kalıpları öğrenmek ve ekip içinde ortak yaklaşım oluşturmak için Power Automate eğitimi sayfamıza göz atabilirsiniz.

Operasyonel görünürlük: dashboard, trend ve kök neden analizi

Hata izleme sadece anlık müdahale değildir; aynı hataların tekrar etmesini önlemek için trend analizi gerekir. Haftalık/aylık raporlarda; en çok hata üreten connector’lar, en sık timeout yaşanan adımlar, en çok retry tüketen akışlar, başarısızlık oranı artan süreçler gibi başlıklar izlenmelidir. Bu sayede teknik borç görünür olur ve iyileştirme backlog’u veriye dayanır.

Loglardan KPI türetme: MTTR, başarısızlık oranı, otomatik toparlanma oranı

Kurumsal karar vericiler için teknik detaydan çok ölçüm önemlidir. Örneğin MTTR (Mean Time To Recovery) düşüyor mu? Toplam run sayısına göre başarısızlık oranı kabul edilebilir mi? Hataların yüzde kaçı otomatik retry ile toparlanıyor? Bu göstergeler, otomasyon programının güvenilirliğini somutlaştırır.

Kök neden analizi için korelasyon kimliği ve sürüm bilgisi

Bir hata dalgası yaşandığında ilk soru şudur: “Bir değişiklik mi oldu?” Bu yüzden akış sürüm bilgisi (ör. manuel bir “VersionTag” alanı) ve korelasyon kimliği (CorrelationId) birlikte tutulmalıdır. Böylece bir deploy sonrası artan hata oranı hızla fark edilir ve geri alma (rollback) kararı daha net verilir.

Hata senaryoları için tasarım kalıpları: telafi, izolasyon, fallback

Her hatayı “düzeltmek” mümkün değildir; bazen en doğru çözüm, etkiyi sınırlamaktır. Bu noktada dayanıklılık kalıpları devreye girer: telafi (compensation), izolasyon (bulkhead) ve fallback. Özellikle çok adımlı süreçlerde, bir adım başarısız olduğunda önceki adımların etkisini geri almak gerekebilir (ör. oluşturulan kaydı silmek, stok rezervasyonunu iptal etmek). Bu telafi adımlarını ayrı bir scope’ta standardize etmek, “yarım kalan işlem” riskini düşürür.

Dead-letter yaklaşımı: başarısız kayıtları kuyrukta tutmak

Tek tek kayıt işleyen akışlarda, bir kayıt hatalıysa tüm batch’in durması istenmez. Bunun yerine başarısız kayıtları bir “dead-letter” listesine/tablolarına atıp, daha sonra tekrar işlemek iyi bir yaklaşımdır. Bu, operasyonun devam etmesini sağlar ve hatalı verinin kontrollü şekilde ele alınmasına imkân verir.

Manuel müdahale kapısı: insan onayı veya istisna yönetimi

Otomasyonun her şeyi çözmesi beklenmemelidir. Bazen en doğru tasarım, belirli istisnalarda insan onayına düşmektir. Ancak bu yaklaşım da izleme ister: kaç kayıt manuel müdahaleye düştü, ortalama bekleme süresi ne, hangi istisnalar tekrar ediyor? Bu metrikler süreç iyileştirmesi için yakıt görevi görür.

Güvenlik ve gizlilik: loglarda kişisel veri riskini yönetmek

Loglama yaparken, özellikle KVKK/GDPR gibi düzenlemeler açısından dikkatli olmak gerekir. Kişisel verileri ham hâliyle loglamak, görünürlük kazandırırken yeni bir risk yaratabilir. Bu nedenle, loglarda maskeleme (ör. e-posta adresinin bir kısmını gizleme), token/secret değerlerini asla yazmama, yalnızca gerekli alanları tutma ve erişim yetkilerini sınırlandırma önemlidir.

Minimum veri prensibi ve maskeleme

Log tasarımında “minimum veri” prensibi, hem güvenliği hem de operasyon verimliliğini artırır. Örneğin müşteri adı yerine müşteri numarası; tam adres yerine bölge kodu gibi alanlar çoğu durumda yeterlidir. Zorunlu durumlarda maskeleme uygulayarak hem izlenebilirliği hem de uyumluluğu birlikte sağlayabilirsiniz.

Uygulanabilir örnek: log kaydı şeması ve arama sorgusu

Aşağıdaki örnek, Dataverse veya benzeri bir tabloda tutulabilecek basit ama etkili bir log şemasını gösterir. Amaç, hem run bazında iz sürmek hem de trend analizi yapabilmektir. Alanları kurumunuzun ihtiyaçlarına göre genişletebilirsiniz; ancak “CorrelationId” ve “BusinessKey” ikilisini korumak, pratikte en çok fayda sağlayan unsurlardan biridir.

{
  "Timestamp": "2026-02-06T10:42:18Z",
  "Environment": "Prod",
  "FlowName": "InvoiceApproval",
  "VersionTag": "v1.8.3",
  "CorrelationId": "INV-20260206-000184",
  "BusinessKey": "InvoiceId=184",
  "Step": "HTTP_CallSupplierAPI",
  "Level": "Error",
  "Outcome": "Failed",
  "StatusCode": 503,
  "ErrorType": "Transient",
  "RetryCount": 2,
  "DurationMs": 14231,
  "Message": "Supplier API unavailable; will escalate after threshold."
}

Log araması için örnek sorgu mantığı

Logları Log Analytics benzeri bir ortama taşıyorsanız, basit bir filtreyle “aynı korelasyon kimliği” etrafındaki tüm adımları toplayabilir, ardından hata üreten step’i izole edebilirsiniz. Böylece tek bir run ekranına bağlı kalmadan, akışlar arası ilişkiyi de kurabilirsiniz.

• Belirli bir “BusinessKey” için son 24 saatteki tüm error kayıtlarını listeleme
• Son 7 günde “StatusCode=429” artış trendini yakalama
• “RetryCount > 0” olan run’ların başarı oranını ölçme
• En yüksek “DurationMs” değerine sahip step’leri sıralama

Sonuç: izlenebilirlik + uyarı + dayanıklılık = güvenilir otomasyon

Power Automate’te hata izleme, sadece teknik bir gereksinim değil; süreç sahipleri için güven, IT için öngörülebilir operasyon ve kurum için sürdürülebilir dijital dönüşüm anlamına gelir. Run geçmişiyle başlayan görünürlük, iyi tasarlanmış log şemasıyla derinleşir; doğru uyarı stratejisiyle aksiyona dönüşür; dayanıklılık kalıplarıyla kesintiler minimize edilir.

Eğer akışlarınız büyüyor, entegrasyon sayınız artıyor ve otomasyonlar kritik süreçlerin parçası hâline geliyorsa; bu makaledeki yaklaşımı “standart işletim modeli” olarak ele alın. Böylece hatalar sürpriz olmaktan çıkar, yönetilebilir bir sinyale dönüşür.