TaliLink Monitoring

AI reports

Periodic analysis of the collected KPIs, written for someone who was not watching.

degraded9/16/2026, 10:06:56 AM — 10:37:33 AM27m ago

The platform itself is up and fast — no outages, no failed requests, and plenty of spare capacity on servers and database for the whole 30-minute window. However, the outgoing email system is rejecting our login credentials, so candidate-facing mail (invites, password resets, and likely stage-transition notifications) is at risk of not being delivered. Someone needs to fix the SMTP username/password. Also be aware that we currently have no instrumentation for registrations, applications, pipeline stages, or emails sent, so 'no problems reported' in those areas means 'not measured', not 'working'.

Findings

SMTP transport failing authentication (535-5.7.8 invalid login)

MailService logged repeated errors around 10:35:08–10:35:10 stating the workspace-failover SMTP transport cannot authenticate and that invites and password-reset mail will not fail over until SMTP_USER/SMTP_PASS are fixed. The same log lines recur across overlapping snapshots, so the true number of failures is not measurable from this data; the credential problem itself is unambiguous.

Email delivery impact cannot be quantified

emailsSent is not instrumented and emailsFailed had no observations in this period, so we cannot tell how many candidate transactional emails (stage transitions, invites, resets) were attempted or lost. Treat mail delivery as unverified rather than healthy.

Database write latency spikes

Write latency averaged 6.26 ms but peaked at 39.9 ms, against read latency averaging 0.55 ms (max 5 ms). With DB CPU at ~4% and only 3–6 connections, this is likely storage/IOPS burstiness rather than load, but it is worth watching if write-heavy flows (applications, stage transitions) slow down.

Very low observed traffic — results may not reflect real user load

API averaged about 2.1 requests/minute (peak 13) and the web frontend about 1.2 requests/minute (peak 29), with web response times sampled only 5 times out of 30 snapshots. The healthy latency and zero-error picture is based on a thin traffic sample and should not be read as proof the system handles production load.

Infrastructure headroom is ample; task count varied

Container CPU 0.96–4.6%, memory 7.8–15.6%, API response 24–50 ms, 100% reachability across 30 cycles. Running ECS tasks ranged 1–2 (avg 1.03), consistent with a brief deployment or task replacement; no 5xx accompanied it.

Not covered by this report

activeTalents and activeStaff are not instrumented — we cannot confirm whether any real candidates or recruiters were actually using the platform during this window.
registrationsSucceeded / registrationsFailed had no observations and registration success is not instrumented — silent signup failures would not appear in this report.
applicationsSubmitted / applicationsFailed had no observations — we cannot confirm that job applications were being accepted or persisted.
pipelineStages is not instrumented — stage transitions (submitted → review → assessment → interview → decision) are entirely unobserved, including any stuck or skipped candidates.
emailsSent is not instrumented and emailsFailed had no observations, so the delivery impact of the SMTP authentication failure is unknown; the only evidence is application log lines.

degraded9/16/2026, 9:35:37 AM — 10:06:35 AM58m ago

TaliLink stayed up and fast for the whole 31-minute window — no failed health checks, no server errors, and plenty of spare CPU, memory and database capacity. The one real problem is email: the mail service repeatedly reported that its SMTP credentials are being rejected ("Username and Password not accepted"), which means candidate-facing mail such as invites, password resets and likely stage-transition notifications may not be going out. Someone needs to check/refresh the SMTP_USER and SMTP_PASS credentials for the mail account. Separately, we have no instrumentation for registrations, applications, pipeline stages or emails sent, so we cannot confirm that candidates are actually able to complete those journeys — the absence of failures there is a visibility gap, not a clean bill of health.

Findings

SMTP authentication is failing — outbound mail likely not being delivered

The MailService logged repeated "SMTP transport is not authenticating (workspace-failover) ... Invalid login: 535-5.7.8 Username and Password not accepted" errors, clustered around 09:44:51–09:44:54, with 36 log occurrences across the grouped reasons (this is a count of log lines, not a count of affected candidates). The message itself states invites and password-reset mail will not fail over until SMTP_USER/SMTP_PASS are fixed; stage-transition mail on the same transport is likely affected too, though that is an inference.

Email success/failure is not measurable from this data

emailsSent is not instrumented and emailsFailed had no observations in the period, so we cannot say how many messages were attempted, dropped or delivered. The SMTP errors are the only signal, and they cannot be converted into a count of undelivered mail.

Availability and latency are healthy

0 of 30 cycles found the API unreachable (100% uptime by this check), health-probe latency averaged 32 ms (max 60 ms), and application response times averaged about 9 ms on the API and 16 ms on the web tier. No 5xx were observed on either tier (0 per minute throughout); 4xx were negligible at about 0.1/min on the API and 0.13/min on the web, peaking at 3/min and 2/min respectively.

Database write latency spiked to 135.9 ms

Write latency averaged 9.57 ms but peaked at 135.9 ms in at least one snapshot, against read latency averaging 0.46 ms (max 8 ms). RDS CPU (avg 4.2%) and connections (avg 3.6, max 6) were low, so this looks like a brief burst or storage-level blip rather than saturation — worth watching, not acting on yet.

Single API task with large headroom, but no redundancy

runningTasks was 1 for all 30 snapshots, with container CPU at ~2.2% and memory ~15%. Capacity is not a concern at this load (API traffic averaged about 17 requests/min, peaking at 76/min), but a single task means no instance-level redundancy; RDS freeable memory was steady at 176–190 MB.

Not covered by this report

Emails sent/delivered is not instrumented, and emailsFailed reported no observations — we cannot quantify how much candidate mail was lost during the SMTP failure, only that authentication was being rejected.
Registration success and failure counts are not instrumented / had no observations, so we cannot confirm whether candidates were able to register during this window.
Application submissions and failures are not instrumented / had no observations, so a broken apply flow would not appear in this report.
Pipeline stage transitions (submitted → review → assessment → interview → decision) are not instrumented, so candidates could be stuck in a stage with no signal here.
Active talent and active staff counts are not instrumented, so the low request rates (API averaging ~17/min, with some snapshots at 0/min) cannot be distinguished between genuinely quiet traffic and users being unable to reach or use the product.

unknown9/16/2026, 9:05:13 AM — 9:35:13 AM1h ago

Every infrastructure signal we can see looks fine: the API and website responded quickly, nothing was down, and no server errors were recorded. But this 30-minute window contains only one measurement, and none of the candidate-facing workflows (registration, job applications, stage-transition emails) are being measured at all — so we cannot confirm candidates were actually able to sign up, apply, or receive email. Treat this as 'infrastructure looks healthy, business outcomes unverified', not as an all-clear.

Findings

API and frontend available with low latency

Uptime 100% with zero unreachable cycles; external API probe 164 ms, internal API response 5.5 ms, web 7.2 ms. API traffic about 20 requests/min and web about 15 requests/min (sampled rates — period totals are not measurable from this data).

No 4xx or 5xx observed

Both API and web error rates sampled at 0 per minute, and there are no open alerts and no recorded failure reasons. With a single sample, this only rules out errors at that instant, not across the full 30 minutes.

Only one snapshot covers the whole window

All min/avg/max values are identical because there is exactly one sample at 09:35:13Z. Roughly 29 minutes of the requested period are effectively unobserved, so a short spike or brief outage would not appear here.

Single ECS task running — no redundancy

runningTasks = 1 with CPU at 1.94% and memory at 15.63%, so capacity is ample but there is no failover; a task crash or deployment would likely cause a full outage window. This is an architecture observation, not a current fault.

RDS freeable memory is modest in absolute terms

186 MB freeable, with CPU 4.52%, 3 connections, read latency 0 ms and write latency 0.5 ms — all otherwise idle-to-light. Whether 186 MB is normal depends on the instance class and historical baseline, neither of which is available here; worth checking against trend before dismissing.

Not covered by this report

Candidate registrations (succeeded and failed) are not instrumented — we cannot tell whether anyone successfully registered, or whether registration was silently broken.
Job application submissions and failures are not instrumented — application success is entirely unverified for this window.
Transactional email at stage transitions is not instrumented (emailsSent not instrumented, emailsFailed had no observations) — candidates could be receiving no email at all and this report would look identical.
Pipeline stage transitions (submitted → under review → assessment → interview → decision) are not instrumented, so stalled or stuck candidates are invisible.
Active talent and active staff counts are not instrumented — the 20 req/min API rate could be health checks and crawlers rather than real users; we cannot distinguish a quiet period from zero usage.