传送错误
Pending
- resolved
现状:决议已生效。 受影响的组件 秘密检测 API(操作)
自动翻译自官方事件更新。
33 Gitguardian incidents · 2021年3月 — official updates, affected components, duration and resolution details.
现状:决议已生效。 受影响的组件 秘密检测 API(操作)
自动翻译自官方事件更新。
状态:解析系统恢复正常运行. 受影响的组件 Webhooks( 操作) 秘密检测 - 扫描检查运行( 操作)
自动翻译自官方事件更新。
现状:已解决。 在数据库查询优化和减少噪音背景工作的负荷之后,没有观察到业绩进一步恶化。 自采用这些方法以来,计量一直保持稳定。 受影响的组件秘密检测 - 扫描检查运行( 操作)
自动翻译自官方事件更新。
状况:已解决 这一事件现在已经得到解决。 在我们小组采取补救措施之后,我们没有看到业绩进一步退化,此后衡量标准一直保持稳定。 受影响的组件秘密检测 - 扫描检查运行( 操作)
自动翻译自官方事件更新。
我们公共摄入管道的性能正在下降。 这是GitHub API持续出道造成的,GitHub在自己的状态页面上承认了这一点. 我们的小组正在积极监测局势。 因为根源在GitHub的一面,所以分辨率取决于GitHub恢复他们的API. 我们的输油管被设计成一旦GitHub恢复就自动恢复,我们将随着形势的发展提供进一步的更新.
GitHub已经开始恢复他们的API, 我们的公众摄取管道正在恢复。 实时事件摄取和承付检索正在恢复。 我们正在继续监测局势,以确认完全恢复,并确保管道正常处理。 一旦事件完全得到解决,我们将提供最后的最新情况.
GitHub恢复了他们的API,我们的公众摄取管道完全恢复了. 实时事件摄取及承诺取回又在正常运行. 这一事件是由上游的GitHub API停电所引起,现已解决. 谢谢你的耐心.
自动翻译自官方事件更新。
我们目前正在调查一个问题,即有些客户在办理检查时可能会遇到时断时续的延误。 我们的小组部署了一个固定方案,并正在积极监测局势。 我们将随着局势的发展提供最新情况。 我们为不便而道歉.
固定装置已经成功部署,情况应该恢复正常。 抱歉给您带来不便.
自动翻译自官方事件更新。
Status: Resolved What happened:From June 1 12:00am UTC to June 1 08:45am UTC, one of the component serving the public monitoring experienced some delays and a growing backlog of unprocessed messages. Impact:No data was lost. The only impact for customers could have been a delay between the detection of a secret and the moment the corresponding incident was created in the customer's dashboard. The problem is now fixed, the faulty component was able to re-start and to process the backlog of messages.
Status: Resolved We deployed a fix today that addressed the check run issues. A brief database load increase was observed post-deployment with no impact on check run results.This incident is now resolved. Affected components Secret Detection - Scan Check Run (Operational)
Due to an availability issue of github.com Actions APIs (https://www.githubstatus.com/incidents/z3c6q056q332), some check runs have timed out on our side, resulting in a neutral status.
We are currently experiencing an incident on GPUB that started around yesterday, 10PM Monday 13th of March. An unexpected activity led to an overload of the queuing system of GPUB. We are deploying a fix to resume processing and catch up with the lag. In terms of data, some events will need to be reprocessed afterward, and we need to assess if some events cannot be processed again.
The fix has been deployed, the processing has resumed at full speed and the awaiting queue will be processing within the next hour.
This incident has been resolved.
Following a upgrade operation of a network component, GIM endpoints have been unavailable most of the time during this incident between 09:48 and 10:24 UTC. Fix has been deployed, situation is still under monitoring.
During deployment of GIM new version, The app was malfunctioning for a few minutes. The events that failed to evaluate during the incidents have been processed again.
We have identified a Network issue on Internal Repositories Monitoring that impacted Hook, Dashboard and API.
Following a DNS misconfiguration, GitGuardian Internal Monitoring platform was unavailable for about 20 minutes. Impact: No realtime scan (webhook): - GitHub events from recent GHE instances and Github.com were redelivered after the incident - Other events (BitBucket, GitLab) have been lost but we fully rescanned repositories when possible No API for secrets detection: CI and pre-commit hook failed. Dashboard was unavailable. Impacted entries: - api.gitguardian.com - dashboard.gitguardian.com - hook.gitguardian.com
Since October 17th, 2022, 12:28am (CEST) we are sending notifications by email for certain incidents already present in your workspace. We are currently investigating this incident.
This incident has been resolved.
On October 17th 2022, at around 5pm GMT, The queuing system in charge of handling Github Check Runs and Real Time Monitoring accumulated tasks that were slow to process and impacted the whole system. The size of the task queue started increasing for several hours straight, delaying processing for all customers. until it started decreasing again and went back to normal the day after at around 1am GMT, where processing time was back to normal. This event occurred again on October 18th 2022, at around 4pm GMT, but has been detected earlier and have been solved at 5pm GMT. Actions were taken to avoid this issue to happen again: It includes a better monitoring of those queues to improve time to detect an issue. The montoring of processing latencies on a end-user point of view will be improved too. More long terms actions are also planned, including implementing mechanisms to avoid accumulating latency in case of slow tasks accumulations.
We are continuing to work on a fix for this issue.
This incident has been resolved.
From Friday 9th Sept 6:30pm UTC to Monday 12th Sept 7:30 UTC, data collectors services were partially down due to an internal error. Github events have been correctly gathered into GitGuardian platform but processing of those events was down. There is no data loss but no alerts have been sent during this period of time. The processing has resumed correctly on Monday 12th Sept 7:30 UTC, the backdata from the week-end is being analyzed and should be caught up around 12pm. Update Monday 12th Sept. 10:25am UTC: Queues processing is slower than expected, ETA for catch up with the lag is postponed to at least to Tuesday morning (UTC), more precise ETA will be communicated when available. Update Monday 12th Sept. 2:05pm UTC: Slowness issues have been solved, queues processing has resumed at normal speed, ETA for catch up with the lag is Monday 12th Sept. 5:00pm UTC
This incident has been resolved.
A fix has been implemented and the systems are getting back to normal progressively.
Start of the issue.
We have an issue with our database. We are still evaluating the impact.
The incident has been resolved at 9h10 CEST.
The incident has been resolved.
We have detected a spike in errors on some endpoints of GitGuardian Internal Monitoring API. Our teams are investigating.