In the free plan you can run only one session at a time. Paid plan users can run multiple sessions depending upon their plan. Click here to checkout multiple session plans and their pricings.

The number of sessions is limited by number of sessions running by a organisation, not by user. Therefore it is entirely possible that you reach out of session limit even if only one or two users are using LambdaTest tool. Co-ordinate with your teammates in this case. If you are sure there is session issue from our end, you can raise a ticket at our support portal here. Don't worry, we have a very fast turnaround time.

By default, if you leave the Lamdatest Live session idle for 5 minutes, the app will prompt a reminder. If no action is taken then LambdaTest would close the live session. You can change this setting from Live settings options. Checkout this link to understand more about it.

Switching tab won't stop or pause the Live session. If left idle for 5 minutes or more, Lambdates will prompt a reminder and if unanswered will close the session.

The moment you close the session, LambdaTest automatically sanitize the whole virtual machine. What that means is that we delete all historical data, downloads, installed extensions, saved passwords, etc. We reset the browsers to factory settings. This automatically logs you out of all pages and auto deletes all data that you may have saved. You would still have access to screenshots and issues you may have generated during the session.

Right now yes. Every time you close a session we would reset all settings. We are working on a way to help you change and save a set of customized default browser settings. If your need is critical and changing browser settings in each new session takes a lot of your time, send us a message from here. We will try to find a solution for you.

There maybe a number of reasons why this happened which inlcude

• LambdaTest test flagged the IP for excessive spam registrations.
• LambdaTest flagged the IP for violating terms of use or privacy policy
• To prevent our system from spam or security threats

LambdaTest test system allows only a limited number of concurrent running sessions per organisation. This limit is defined by the plan that you have subscribed. If you need more concurrent sessions, you can change your plan here, or contact one of our sales executive by leaving a message here.

It's simple. In real time browser, on left side you will find multiple action buttons in the controller. One of them will be a screenshot button with camera icon. Just click that and in no time your screenshot will be recorded. Once recorded, an image editor will pop up where you can edit the screenshot, mark it as a bug and comment about the details. Lastly, you can find them anytime in test logs section of the menu.

By going to the issue tracker, you can add your teammates as watchers for the particular issue and you can also assign them the issue by marking them as 'assignee'. Incase the team-mate is not added yet, you will also find an option in the tracker to invite them.

LambdaTest Live has all major developer debugging tools like Firebug, Web Developer, YSlow etc. For complete list of Developer tools that comes pre-installed with the browsers, checkout this page here.

Yes. You have full access to browser extensions and therefore can install any additional tool you like. However that tool be deleted once you close the Live session and you would have to reinstall it again in next session to use. If you are facing any problem around installing a tool on browser, raise an issue in LambdaTest Support portal and we would be glad to help you out.

To know more about browsers os devices and resolutions supported by LambdaTest checkout this page here.

Yes. You can share these screenshots with your team. To know more about how you can do it, check out this tutorial guide here.

LambdaTest comes with enterprise level local tunneling features. You can connect your local or production servers with LambdaTest Servers via secure SSH protocols and test your secure pages easily.

LambdaTest won't stop or pause the screenshot generation process. LambdaTest automatic screenshot tool will generate screenshots and then will wait for your further actions.

It means that you have either reached the number of concurrent sessions limit or there is some other type of testing session running somewhere in your account. Check all your tabs in all browsers and close any live or automated screenshot session running in them.

Yes, you can. To know more about it checkout this guide here.

We do not have any information or system security certificate at this moment. We have however, applied for Service Organisation Control (SOC) 2 Report compliance certification from US agencies.

LambdaTest is a firm believer in secure experience and multifaceted security protocols, to ensure that every aspect including architecture, engineering, testing, and deployment, follows and complies with industry leading standards of security. As first line of defense, LambdaTest application is protected by AWS's firewalls which are tasked with countering regular DDoS attacks and malicious network intrusions. The next line of defense is LambdaTest's own application firewall protocols which are tasked with protecting the application against spam, ill-intent users, and malicious IP. We have also implemented secure user access policies for accessing LambdaTest platform and only users with valid user credentials can access the application. We have also implemented role based access to the application, each role having different access levels.

Whenever a user initiates a test at LambdaTest platform, they are allotted a thoroughly sanitized virtual machine. And as soon as a session ends, all data including cookies, registry, caches, and running processes are deleted and all browser settings are reset to default values. Each virtual machine has to pass a series of automated tests before it is used again. Any machine that fails a test gets redacted from the pool for auditing and manual cleaning. At the time of test only the user has access to machine and not even LambdaTest has access to the user's running test session. All machines have strict security protocols that prohibit any user from installing any external software in the machines.

In our application we have implemented HTTPS by default, and use VNC protocols for secure data transfer. This data is also encrypted to ensure that data is not compromised in-transit.

All our hosting centers are chosen based on their record of established security policies and excellent history. Our selection process is rigorous and we partner with only the best providers across globe that have been certified by major compliance regulators.

All data saved in our application like login credentials, secure access keys, usage logs, test history, and billing details, are stored in an encrypted format.

We have implemented strict 24x7 security protections at our on-premise development centers. Only authorized individuals have access to building and LambdaTest office premises. Our application data is hosted on industry leading hosts like Amazon Web Services, who have been thoroughly tested by multiple third party auditors for security. You can also read more about Amazon Web Service's Security Here.

All our data is hosted and stored in Amazon Web Services infrastructure, which has multi-level disaster recovery features. We implement all AWS guidelines and protocols on Disaster Management as advised in this document by here

Yes. All our employees sign confidentiality agreements which extends to user agreements between LambdaTest and Clients. Also, we have strict user role based access to all our customer data therefore, only most important employees have access to only relevant data.

. Our application is micros-services based product. Database is restricted from public access. It is only accessible to the application though encrypted authentication based APIs and that also over a secure private network.

We here at LambdaTest follow Agile development methodologies with dedicated teams for automated deployment and testing. We use Jenkins as our preferred Continuous integration platform and use Sonar Cube for automated code quality control. We ensure maximum possible code coverage in our automated tests and each release is passed only before it pass all test scenarios.

We periodically tests our applications for vulnerability both through automated and manual means. We perform regular audits of databases to check for irregularities, and our ELK stack implementation gives real-time insights on any possible attacks.

. Access to production system is strictly controlled though role based authentication access. No LambdaTest employee has complete access to all data, each having their relevant role based access to data. Each employee has his/her own email based authentication passwords for accessing applications and after termination we revoke their complete access to the application. In addition we maintain automated logs of each database ingress and regularly monitor the logs to find discrepancies.

All user access is password protected. In addition user sign-ups are verified through a two-step verification workflow.

At LambdaTest, we maintain a variety of logs such as syslog (system logs), auth (authentication) logs, firewall logs, web server logs, application server logs, database server logs, netflows etc. We have an inhouse implementation of ELK stack for logging and business intelligence. Our implementation gathers and consolidates data from all micro-applications into a secure private network. The data is used for product analysis by product team through our custom log processing and BI system. The BI system in turn is secured thorugh a IP based access policy. In addition only authorized LambdaTest employees has access to relevant pieces of data based on their role. All log data is saved in encrypted format private storage volumes that is encrypted usign DM-Crypt disk encryption system

We follow SemVer versioning standards and publish hot-fixes and patches as it is required.

Yes. We have separate Production, Dev, and Test Environments. Each Environment is hosted in separate instances and is secured behind a private network.

All environments are hosted on independent AWS instances. Only Live environment has critical user data. Rest of the environments have dummy or simulated data that covers all use cases.

We perform periodic system vulnerability scans, both automated and manual, using a OpenVAS based solution. We check for all major vulnerabilities and security risks as enlisted in open source databases like https://nvd.nist.gov/.

Our application is hosted on Amazon Web Services and we follow all DDoS mitigation guidelines detailed by AWS in this documentation paper . We use services such as Amazon Route 53, Amazon CloudFront, Elastic Load Balancing, and AWS WAF to control and absorb traffic, and deflect unwanted requests. We also have a Cisco ASA firewall in place as added security measure. In additon to all this we have put into place custom firewall and security measures based on Fail2Ban intrusion protection framework to prevent brute-force attacks.

We have implemented advanced analytics using Kibana, Kubernetics, and AWS data tools. We monitor all our networks constantly for suspicious activity. We also use Elastic.co's Beats product for shipping data. Beats comes with in-built monitoring and data visualization tools that help in real-time monitoring of application.

We perform periodic system vulnerability scans, both automated and manual, using a OpenVAS based solution. We check for all major vulnerabilities and security risks as enlisted in open source databases like https://nvd.nist.gov/.

Yes. All user credentials are stored in a manner compliant with all NIST guidelines as defined here.

All user data is stored as encrypted data in secure AWS storage hosted databases. We use AWS S3 for data storage and have enabled advanced AES256 encryption standards for Data at Rest. For Data in transit we use VNC and WSS security and encryption protocols.

All data such as user credentials are secured in encrypted format and no LambdaTest employee can access it, including administrators. User data such as company details, user contact details, test logs, etc. can be access by only relevant developers. We have strict user role based data access and only relevant developers have access to parts of user data. This security access is audited every month based on development and testing sprint plans.

We use AWS services like AWS S3 to store and take backups of our data. All data stored on AWS instances are stored using advanced AES256 encryption standards. Any data that is not critically required gets deleted through standard DELETE requests on S3 buckets. However we have implemented versioning and rollback steps to prevent accidental deletion of data. Therefore, even delete requests do not immediately delete all data. For that we have implemented provisions to scrub all data including the historical backup data on client requests.

Our application is hosted entirely on third party hosting providers like AWS, Hetzner, etc. All our hosting partners have very high security protocols. For example checkout AWS security protocols here, or Hetzner Security protocols here

We, here, at LambdaTest follow a 6 step incident reponse process. The various stages of the response proces are prepration, identification, containment, eradication, recovery, and learning. We use industry leading practices for each step and test our response workflow once a month.

In case of an identified breach, all related users are notified of the breach immediately so that they can take necessary measures to prevent further loss. We share this information with our signup users through our email channels, and also notify users through social media platforms like LinkedIn, Facebook, and Twitter.